Payment method, apparatus, device, and storage medium

Abstract

This application discloses a payment method, apparatus, device, and storage medium. The payment method includes: sending a query request to a resource payment server corresponding to the payment mini-program based on a payment order from a merchant mini-program within a main application; the query request is used to request the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program, wherein the payment mini-program is an application with payment functionality embedded within the main application; upon receiving a query feedback result from the resource payment server indicating that an authorization relationship has been established between the application account and the payment account, sending a first payment instruction to the resource payment server to instruct the payment mini-program to process the payment order; thereby, by using payment methods other than those provided by the payment control provided by the owner of the main application, the order from the merchant mini-program can be paid, increasing payment channels and improving payment efficiency.

Description

Technical Field

[0001] This application belongs to the field of payment technology, and in particular relates to a payment method, device, equipment and storage medium. Background Technology

[0002] With the development of technology, the payment industry is accelerating its internetization, and users have more and more ways to pay their bills. For example, users can make mobile payments through applications with payment functions.

[0003] In related technologies, in order to provide users with more convenient services, these payment-enabled applications often embed merchant mini-programs. Users can place orders in these merchant mini-programs and request payment for the orders within the merchant mini-program. However, users can only pay for orders in merchant mini-programs through the payment controls provided by the application's owner and cannot pay through other methods. This makes the payment methods relatively limited and affects payment efficiency. Summary of the Invention

[0004] This application provides a payment method, apparatus, device, and storage medium that can solve the problems of limited payment methods and low payment efficiency in related technologies.

[0005] In a first aspect, embodiments of this application provide a payment method applied to a main application server, which may include:

[0006] Receive payment orders from merchant mini-programs within the main application;

[0007] Based on the payment order, a query request is sent to the resource payment server corresponding to the payment mini-program. The query request is used to ask the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The payment mini-program is an application with payment function embedded in the main application.

[0008] Receive query feedback results sent by the resource payment server;

[0009] If the query feedback results indicate that the application account and payment account have established an authorization relationship, a first payment instruction is sent to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order.

[0010] Secondly, embodiments of this application provide a payment method applied to a resource payment server, which may include:

[0011] Receive query requests sent by the main application server;

[0012] Based on the query request, the query feedback result determines whether an authorization relationship has been established between the application account and the payment account. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment function embedded in the main application.

[0013] Send the query feedback results to the main application server;

[0014] Upon receiving the first payment instruction from the main application, the payment order is processed through the payment account of the payment mini-program.

[0015] Thirdly, embodiments of this application provide a payment method applied to electronic devices, which may further include:

[0016] Displays the first interface of the merchant's mini-program in the main application;

[0017] Upon receiving the first input to the first interface, the interface switches to the second interface. The first input is to confirm the submission of a payment order in the merchant mini-program. The second interface is the interface for the payment mini-program to process the payment order. The payment mini-program is an application with payment function embedded in the main application.

[0018] If it is confirmed that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the payment result after the payment mini-program processes the payment order will be displayed.

[0019] Fourthly, embodiments of this application provide a payment method applied to electronic devices, which may further include:

[0020] The third interface of the main application is displayed. The third interface includes N payers, where N is an integer greater than 1.

[0021] Upon receiving a third input from the user regarding the target payer among N payers, the interface switches from the third screen to the fourth screen. The fourth screen is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment function embedded in the main application. The payment interface includes the payment code provided by the payment mini-program.

[0022] If it is confirmed that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the fifth interface is displayed. The fifth interface includes the payment result after the payment mini-program processes the payment order; the owner of the payment mini-program is different from the owner of the main application.

[0023] Fifthly, embodiments of this application provide a payment device applied to a main application server, the device including:

[0024] The receiving module is used to receive payment orders from merchant mini-programs in the main application;

[0025] The sending module is used to send a query request to the resource payment server corresponding to the payment mini-program based on the payment order. The query request is used to ask the resource payment server to determine whether the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The payment mini-program is an application with payment function embedded in the main application.

[0026] The receiving module is also used to receive query feedback results sent by the resource payment server;

[0027] The sending module is also used to send a first payment instruction to the resource payment server when the query feedback result indicates that the application account and the payment account have established an authorization relationship. The first payment instruction is used to instruct the payment mini-program to process the payment order.

[0028] Sixthly, embodiments of this application provide a payment device applied to a resource payment server, the device including:

[0029] The receiving module is used to receive query requests sent by the main application server;

[0030] The determination module is used to determine the query feedback result of whether the application account and the payment account have established an authorization relationship based on the query request. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment function embedded in the main application.

[0031] The sending module is used to send query feedback results to the main application server;

[0032] The processing module is used to process payment orders through the payment account of the payment mini-program upon receiving the first payment instruction sent by the main application.

[0033] In a seventh aspect, embodiments of this application provide a payment device applied to an electronic device, which may include:

[0034] The display module is used to display the first interface of the merchant mini-program in the main application. The first display module is used to display the first interface of the merchant mini-program in the main application.

[0035] The display module is also used to switch the display from the first interface to the second interface when a first input is received on the first interface. The first input is an input to confirm the submission of a payment order in the merchant mini-program, and the second interface is the interface for the payment mini-program to process the payment order. The payment mini-program is an application with payment function embedded in the main application.

[0036] The display module is also used to display the payment result of the payment order processed by the payment mini-program, provided that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship.

[0037] Eighthly, embodiments of this application provide a payment device applied to an electronic device, which may include:

[0038] The display module is used to display the third interface of the main application. The third interface includes N payers, where N is an integer greater than 1.

[0039] The display module is also used to switch from the third interface to the fourth interface when the user receives the third input for the target payer among N payers. The fourth interface is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment function embedded in the main application. The payment interface includes the payment code provided by the payment mini-program.

[0040] The display module is also used to display a fifth interface when it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The fifth interface includes the payment result after the payment mini-program processes the payment order; the owner of the payment mini-program is different from the owner of the main application.

[0041] Ninthly, embodiments of this application provide a computing device, the computing device including: a processor and a memory storing computer program instructions;

[0042] When the processor executes computer program instructions, it implements the payment method as shown in the first aspect, the payment method as shown in the second aspect, the payment method as shown in the third aspect, or the payment method as shown in the fourth aspect.

[0043] In a tenth aspect, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the payment method as shown in the first aspect, the second aspect, the third aspect, or the fourth aspect.

[0044] In the eleventh aspect, embodiments of this application provide a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the payment method shown in the first aspect, the second aspect, the third aspect, or the fourth aspect.

[0045] In a twelfth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement a payment method as shown in the first aspect, the second aspect, the third aspect, or the fourth aspect.

[0046] The payment method, apparatus, device, and storage medium of this application embodiment allow the main application server to send a query request to the resource payment server corresponding to the payment mini-program based on the payment order from the merchant mini-program within the main application. The query request requests the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The payment mini-program is an application with payment functionality embedded within the main application. Upon receiving a query feedback result from the resource payment server indicating that an authorization relationship has been established between the application account and the payment account, a first payment instruction can be sent to the resource payment server. This first payment instruction instructs the payment mini-program to process the payment order. Therefore, this payment method allows payment of orders in the merchant mini-program through payment methods other than those provided by the main application provider, increasing payment channels and improving payment efficiency. Furthermore, by using the payment mini-program within the main application to pay for orders in the merchant mini-program, there is no need to redirect to a page outside the main application, such as an HTML5 page, or to a third-party payment application to complete the payment. This reduces the user's need to trigger the launch of a third-party application and return to the main application, improving the convenience of user payments. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of a payment architecture according to an embodiment of the payment method provided in this application;

[0049] Figure 2 This is one of the flowcharts illustrating a payment method provided in an embodiment of this application.

[0050] Figure 3This is the second flowchart of a payment method provided in an embodiment of this application.

[0051] Figure 4 A flowchart illustrating a payment method based on a main application server, provided as an embodiment of this application;

[0052] Figure 5 A flowchart illustrating a payment method based on a resource payment server, provided as an embodiment of this application;

[0053] Figure 6 This is one of the interactive flow diagrams of a payment method provided in an embodiment of this application;

[0054] Figure 7 A second schematic diagram of the interaction flow of a payment method provided in an embodiment of this application;

[0055] Figure 8 A flowchart illustrating a payment method based on an electronic device, as provided in this application embodiment;

[0056] Figure 9 One of the interface diagrams for a payment method based on an electronic device provided in this application embodiment;

[0057] Figure 10 A flowchart illustrating a payment method based on an electronic device, as provided in this application embodiment;

[0058] Figure 11 A second interface diagram of a payment method based on an electronic device provided in this application embodiment;

[0059] Figure 12 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application;

[0060] Figure 13 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application;

[0061] Figure 14 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application;

[0062] Figure 15 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application;

[0063] Figure 16 This is a schematic diagram of the structure of a computer device provided in one embodiment of this application. Detailed Implementation

[0064] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0065] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0066] In related technologies, to provide users with more convenient services, some applications offer payment functions, enabling users to make mobile payments through these payment-enabled applications. These payment-enabled applications sometimes also embed merchant mini-programs, where users can select the desired services or goods, place orders, and confirm payment within the merchant mini-program. Payment for the merchant mini-program order can then be made using payment controls provided by the application's developer.

[0067] However, this payment method has limitations: users can only pay through the payment controls provided by the application's developer and cannot pay through other methods. This makes the payment options relatively limited and affects payment efficiency. Furthermore, although it's possible to redirect to a third-party application for payment, this process increases user interaction and complexity.

[0068] Based on this, to solve the aforementioned problems, this application provides a payment method based on a payment mini-program. The main application server can send a query request to the resource payment server corresponding to the payment mini-program based on payment orders from merchant mini-programs within the main application. The query request requests the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The payment mini-program is an application with payment functionality embedded within the main application. Then, upon receiving a query feedback result from the resource payment server indicating that an authorization relationship has been established between the application account and the payment account, a first payment instruction can be sent to the resource payment server. This first payment instruction instructs the payment mini-program to process the payment order. Thus, this payment method allows payment of orders in merchant mini-programs through payment methods other than those provided by the main application provider, increasing payment channels and improving payment efficiency. Furthermore, by using the payment mini-program within the main application to pay for orders in merchant mini-programs, there is no need to redirect to pages outside the main application, such as HTML5 pages, or to third-party payment applications to complete the payment. This reduces the user's need to trigger the launch of third-party applications and return to the main application, improving the convenience of user payments.

[0069] Based on this, embodiments of this application provide a payment method, apparatus, device, and storage medium. The following will describe in conjunction with the appendix... Figures 1 to 11 This application describes in detail the payment methods, apparatus, servers, and storage media of the embodiments thereof. It should be noted that these embodiments are not intended to limit the scope of this application.

[0070] First, the payment architecture of the payment method provided in the embodiments of this application will be described.

[0071] like Figure 1 As shown, the payment architecture 10 may include an electronic device 101, a main application server 102, a resource payment server 103, and a resource management server 104.

[0072] The payment architecture 10 described above will be explained in detail below.

[0073] In one example, electronic device 101 can be used for human-computer interaction with a user, such as receiving and responding to user input. In another example, electronic device 101 has a main application installed, and electronic device 101 is used to interact with the main application server 102 corresponding to the main application to respond to user input.

[0074] In one example, the main application server 102 can interact with the electronic device 101 where the main application resides, for example, updating the version of the main application installed on the electronic device 101 and providing data support for the main application. In another example, the main application server 102 can interact with the resource payment server 102, wherein the payment program corresponding to the resource payment server 102 can be embedded in the main application as a payment mini-program within the main application to implement payment functionality. For example, the main application server 102 can specifically be used to send a query request to the resource payment server 102 corresponding to the payment mini-program to request the resource payment server to determine whether an authorization relationship has been established between the application account of the main application server and the payment account of the payment mini-program; and to receive the query feedback results sent by the resource payment server 102. In another example, the main application server 102 can provide payment controls for the main application in the electronic device 101 and interact with the resource management server 104. The main application server 102 can send a resource transfer request to the resource management server 104, which carries information related to the payment order, so that the resource management server 104 can execute the corresponding resource transfer method according to the payment order, such as transferring resources in the resource card bound to the application account of the main application according to the payment order. The main application server 102 can also receive the resource transfer result corresponding to the resource transfer request sent by the resource management server 104.

[0075] In one example, the resource payment server 103 can interact with the main application server 102. The resource payment server 103 provides data support for the payment mini-program embedded in the main application service. Based on this, through interaction with the main application server 102, it prompts the main application server 102 to provide corresponding prompts to the user through the payment mini-program, such as prompting the user to enter user identity credentials or user communication device signal. Furthermore, the resource payment server 103 receives query requests sent by the main application server 103 and, based on the query requests, determines whether an authorization relationship has been established between the application account of the main application service and the payment account of the corresponding payment mini-program of the resource payment server. Finally, the resource payment server 103 sends the query feedback result to the main application server. In another example, the resource payment server 103 can also interact with the resource management server 104. Specifically, the resource payment server 103 sends a card binding request to the resource management server 104, requesting the resource management server to bind a first resource card to the payment account of the payment mini-program based on the authorization code, authorization interface credential, user identity identifier, and user authorization information. The resource payment server 103 also receives resource card information from the resource management server 104 regarding the first resource card bound to the payment account. Furthermore, the resource payment server 103 sends a resource transfer request to the resource management server 104, carrying information related to the payment order, so that the resource management server 104 can execute a corresponding resource transfer method based on the payment order, such as transferring resources from the resource card bound to the payment account of the payment mini-program. Finally, the main application server 102 can also receive the resource transfer result corresponding to the resource transfer request sent by the resource management server 104.

[0076] The resource management server 104 can interact with the main application server 102 and the resource payment server 103. Specifically, the resource management server 104 can bind the first resource card to the payment account of the payment mini-program based on the authorization code, authorization interface credential, user identity identifier, and user authorization information. The resource management server 104 can also execute corresponding resource transfer methods for payment orders based on resource transfer requests sent by the main application server 102 and the resource payment server 103, such as transferring resources from the resource card bound to the payment account of the payment mini-program according to the payment order.

[0077] Based on the above, Figure 1 The payment architecture shown, combined with Figure 2 The payment method provided in the embodiments of this application will be described in detail.

[0078] like Figure 2 As shown, the payment method in this application embodiment may include S201 to S222, and the specific steps are as follows.

[0079] S201, electronic device 101 receives a fourth input from a user to at least one merchant app in the main application of electronic device 101;

[0080] S202, the electronic device 101 responds to the fourth input and displays the first interface of the merchant mini-program corresponding to the fourth input;

[0081] S203, when the electronic device 101 receives the first input from the user on the first interface, it switches from the first interface to the second interface. The first input is an input to confirm the submission of a payment order in the merchant mini-program. The second interface is the interface for the payment mini-program to process the payment order. The payment mini-program is an application with payment function embedded in the main application.

[0082] S204, the electronic device 101 can send the merchant's payment order to the main application server 102 through the main application;

[0083] It should be noted that, upon receiving the first input, the electronic device 101 may first execute S204 and then switch from the first interface to the second interface; of course, the electronic device 101 may first switch from the first interface to the second interface and then execute S204; similarly, the electronic device 101 may execute S204 while switching from the first interface to the second interface.

[0084] S205, the main application server 102 sends a query request to the resource payment server 103 corresponding to the payment mini-program based on the payment order;

[0085] S206, Resource payment server 103 receives the query request and, based on the query request, determines the query feedback result regarding whether the application account of the main application and the payment account of the payment mini-program have established an authorization relationship;

[0086] S207, Resource payment server 103 sends query feedback results to main application server 102;

[0087] S208, the main application server 102 receives the query feedback result, and if the query feedback result indicates that the application account and the payment account have established an authorization relationship, it sends a first payment instruction to the resource payment server 103. The first payment instruction is used to instruct the payment applet to process the payment order.

[0088] S209, the resource payment server 103 receives the first payment instruction and sends a first resource transfer request to the resource management server 104 according to the first payment instruction. The first resource transfer request includes a payment order, which may include the third resource card bound to the payment account of the payment mini-program, the resource transfer amount of the payment order, and the information of the payee's account (such as the account information of the merchant corresponding to the merchant mini-program).

[0089] S210, the resource management server 104, based on the first resource transfer request, transfers the resources of the transfer amount from the third resource card bound to the payment account, and transfers the resources of the transfer amount to the payee's account;

[0090] S211, the resource management server 104 sends a first result to the resource payment server 103. The first result is used to indicate that the resource transfer processing of the payment order has been completed.

[0091] S212, upon receiving the first result, the resource payment server 103 sends the first result to the electronic device 101 through the main application server 102;

[0092] S213, the electronic device 101 displays a third interface based on the first result, the third interface including the payment result after the payment applet processes the payment order.

[0093] Additionally, in one possible embodiment, the query feedback result can also indicate that the application account and the payment account have not established an authorization relationship. That is, if the query feedback result carries a first information retrieval request, the query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship, and the first information retrieval request is used to request the first communication device number bound to the application account. Based on this, after S207, such as Figure 3 As shown, the payment method may also include:

[0094] S214, the main application server 102 sends a first real-name matching request to the resource payment server 103 according to the first information; wherein, the first real-name matching request includes a first communication device number bound to the application account, and the first real-name matching request is used to request to determine whether the first communication device number is associated with the payment account;

[0095] S215, the resource payment server 103 receives the first real-name matching request sent by the main application server 102 and obtains the second communication device number bound to the payment account;

[0096] S216, when the resource payment server 103 obtains the second communication device number bound to the payment account, it determines whether the first communication device number and the second communication device number match according to the first real-name matching request;

[0097] S217, the resource payment server 103 sends a second real-name matching request to the main application server 102 after determining that the first communication device number and the second communication device number match.

[0098] S218, the main application server 102 receives a second real-name matching request sent by the resource payment server 103. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number and the second communication device number bound to the payment account match. The server also obtains a second user identity credential bound to the application account. S219, if the main application server 102 obtains the second user identity credential bound to the application account, it determines whether the first user identity credential and the second user identity credential match.

[0099] S220, if the main application server 102 matches the first user's identity credentials and the second user's identity credentials, it sends an establishment notification to the resource payment server. The establishment notification is used to notify the resource payment server to establish an authorization relationship between the application account and the payment account. Then, S208 can be executed.

[0100] Therefore, the main application server can send a query request to the resource payment server corresponding to the payment mini-program based on the payment order from the merchant mini-program within the main application. The query request is used to ask the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The payment mini-program is an application with payment functionality embedded in the main application. Then, upon receiving the query feedback result from the resource payment server indicating that an authorization relationship has been established between the application account and the payment account, a first payment instruction can be sent to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. Thus, this payment method can pay for orders in the merchant mini-program through payment methods other than those provided by the main application provider, increasing payment channels and improving payment efficiency. Furthermore, paying for orders in the merchant mini-program within the payment mini-program of the main application does not require redirection to pages outside the main application, such as HTML5 pages, nor does it require redirection to a third-party payment application to complete the payment, reducing the user's operations of triggering the launch of a third-party application and returning to the main application, thereby improving the convenience of user payments.

[0101] Therefore, to better illustrate the above content, the following will be combined with... Figures 4 to 9 The payment method provided in the embodiments of this application will be described.

[0102] First, the following combination Figure 4 The payment method based on the main application server provided in the embodiments of this application will be described in detail.

[0103] Figure 4 A flowchart illustrating a payment method based on a main application server, provided as an embodiment of this application.

[0104] like Figure 4 As shown, this payment method can be applied to, for example... Figure 1 The main application server in the illustrated payment architecture may include the following steps in its payment method:

[0105] Step 410: Receive payment orders from merchant mini-programs within the main application; Step 420: Based on the payment order, send a query request to the resource payment server corresponding to the payment mini-program, wherein the query request is used to request the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program, and the payment mini-program is an application with payment functionality embedded in the main application; Step 430: Receive query feedback results from the resource payment server; Step 440: If the query feedback results indicate that an authorization relationship has been established between the application account and the payment account, send a first payment instruction to the resource payment server, wherein the first payment instruction is used to instruct the payment mini-program to process the payment order.

[0106] Therefore, this payment method allows users to pay for orders within merchant mini-programs using payment controls other than those provided by the main application provider, increasing payment options and improving payment efficiency. Furthermore, by using the payment mini-program within the main application to pay for orders within the merchant mini-program, users do not need to be redirected to pages outside the main application, such as HTML5 pages, nor to third-party payment applications to complete the payment. This reduces the number of user actions required to launch third-party applications and return to the main application, thus improving the convenience of user payments.

[0107] The above steps are explained in detail below:

[0108] First, regarding step 430, in one or more possible embodiments, if the query feedback result carries a first information acquisition request, the query feedback result is used to characterize that the application account and the payment account have not established an authorization relationship, and the first information acquisition request is used to request the first communication device number bound to the application account.

[0109] Based on this, after step 430, it can be determined whether the first communication device number bound to the application account and the second communication device number bound to the payment account match. If they match, it is further verified whether the first user identity credential bound to the payment account and the second user identity credential bound to the application account match. If they match, an authorization relationship between the application account and the payment account is established. Based on this, the payment method may also include:

[0110] Step 4401: Based on the first information acquisition request, send a first real-name matching request to the resource payment server; wherein, the first real-name matching request includes a first communication device number bound to the application account, and the first real-name matching request is used to request to determine whether the first communication device number is associated with the payment account;

[0111] Step 4402: Receive a second real-name matching request sent by the resource payment server. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number matches the second communication device number bound to the payment account.

[0112] Step 4403: If a second user identity credential bound to the application account is obtained, determine whether the first user identity credential and the second user identity credential match.

[0113] Step 4404: If the first user identity credential and the second user identity credential match, send an establishment notification to the resource payment server. The establishment notification is used to notify the resource payment server to establish the authorization relationship between the application account and the payment account.

[0114] The first user identity credential can be information representing the user's identity, such as an authorization identifier (Auth id) or an ID card number. Here, the main application server can receive the Auth id sent by the resource payment server. The Auth id can uniquely identify a user on the resource payment server and is not the account user ID of the payment mini-program. Thus, the first user identity credential can be used.

[0115] In one embodiment, if the first communication device number and the second communication device number do not match, the user needs to be prompted to enter user identity credentials. Then, the user's entered user identity credentials are matched with the second user identity credentials. If they match, the user's biometric authentication, such as facial or iris recognition, is initiated. If the authentication is successful, an authorization relationship between the application account and the payment account can be established. Based on this, after step 4401 above, the payment method may further include:

[0116] Step 4405: Receive the first instruction sent by the resource payment server;

[0117] Step 4406: According to the first instruction, the user is prompted to enter their identity credentials through the payment mini-program;

[0118] Step 4407: Upon receiving the target user identity credential input by the user, match the target user identity credential with the second user identity credential bound to the application account;

[0119] Step 4408: If the target user's identity certificate matches the second user's identity certificate, prompt the user to extract biometric features via the payment mini-program;

[0120] Step 4409: If the user's target biometric information is obtained and the target biometric information matches the preset biometric information, a notification is sent to the resource payment server.

[0121] In another embodiment, if the first communication device number and the second communication device number match, and the payment mini-program is verified with real name and consistent with the main application, i.e., the first user identity credential and the second user identity credential match, then to ensure the accuracy of verification, the user's biometric features can be collected in real time to further verify the user's identity. Based on this, the aforementioned step 4404 may specifically include:

[0122] Step 44041: If the first user identity certificate and the second user identity certificate match, prompt the user to extract biometric features through the payment mini-program.

[0123] Step 44042: If the user's target biometric information is obtained and the target biometric information matches the preset biometric information, a notification is sent to the resource payment server.

[0124] In another embodiment, if the first communication device number and the second communication device number match, and the payment mini-program is verified with real name, but the first user identity credential and the second user identity credential do not match, the user can be prompted to enter the target user identity credential in real time. Then, the user's entered user identity credential is matched with the second user identity credential. If they match, the user's biometric authentication, such as face or iris recognition, is initiated. If the authentication is successful, an authorization relationship between the application account and the payment account can be established. Based on this, after step 4403 mentioned above, the payment method may further include:

[0125] Step 4501: If the first user identity credential and the second user identity credential do not match, prompt the user to enter the user identity credential through the payment mini-program;

[0126] Step 4502: Upon receiving the target user identity credential input by the user, match the target user identity credential with the second user identity credential bound to the application account;

[0127] Step 4503: If the target user's identity certificate matches the second user's identity certificate, prompt the user to extract biometric features via the payment mini-program;

[0128] Step 4504: If the user's target biometric information is obtained and the target biometric information matches the preset biometric information, a notification is sent to the resource payment server.

[0129] In another embodiment, if the first communication device number and the second communication device number match, but the payment mini-program has not been real-name authenticated, then after step 4401 above, the payment method may further include:

[0130] Step 4601: Receive the second instruction sent by the resource payment server;

[0131] Step 4602: According to the second instruction, the user is prompted to enter their identity credentials through the payment mini-program;

[0132] Step 4603: Upon receiving the target user identity credential input by the user, match the target user identity credential with the second user identity credential bound to the application account;

[0133] Step 4604: If the target user's identity credential matches the second user's identity credential, prompt the user to extract biometric features via the payment mini-program.

[0134] Step 4605: If the user's target biometric information is obtained and the target biometric information matches the preset biometric information, a notification is sent to the resource payment server.

[0135] In another embodiment, if the payment mini-program is not bound to the user's communication device number, the payment method may further include the following before step 4402 above:

[0136] Step 4701: Receive the third instruction sent by the resource payment server;

[0137] Step 4702: According to the third instruction, the user is prompted to enter the user's communication device number through the payment mini-program;

[0138] Step 4703: Upon receiving the target user communication device number input by the user, a user communication device notification is sent to the resource payment server. The user communication device notification includes the target user communication device number and is used to notify the resource payment server to identify the target user communication device number as the second communication device number bound to the payment account.

[0139] In another or more possible embodiments, in some scenarios, if a user identity credential is associated with multiple user communication device numbers, the payment account of the payment mini-program corresponding to the user communication device number can be M payment accounts. To ensure the accuracy of determining the establishment of the authorization relationship, M is an integer greater than 1. Before step 430, the payment method may further include:

[0140] Step 4801: Receive the fifth instruction sent by the resource payment server;

[0141] Step 4802: According to the fifth instruction, the user is prompted to select the target payment account from the M payment accounts through the payment mini-program shown. The target payment account is the payment account that establishes an authorization relationship with the application account.

[0142] Step 4803: Send the target payment account specified by the user to the resource payment server so that the resource payment server can provide feedback on whether the application account of the main application and the target payment account have established an authorization relationship.

[0143] Then, after step 440, if the payment account of the payment mini-program is not bound to a resource card, in one or more possible embodiments, the payment method may further include:

[0144] Step 4901: Receive the fourth instruction sent by the resource payment server;

[0145] Step 4902: According to the fourth instruction, the user is prompted to bind a resource card to the payment account via the payment mini-program;

[0146] Step 4903: Upon receiving user input of a first resource card linked to a payment account, send the information of the first resource card to the resource payment server. In another or more possible embodiments, if the resource card is frozen or the account is blocked, the payment method may further include the following after step 440:

[0147] Receive abnormal instructions sent by the resource payment server. The abnormal instructions are used to indicate that the account status of the payment account and / or the status of the resource card bound to the payment account is a preset abnormal status.

[0148] Based on the abnormal instruction, a second resource transfer request is sent to the resource management server. The second resource transfer request includes a payment order, which includes the second resource card bound to the application account, the resource transfer amount of the payment order, and the information of the payee's account. The second resource transfer request is used to request the resource management server to process the payment order based on the second resource card.

[0149] It should be noted that in some embodiments, the owner of the payment mini-program is different from the owner of the main application. In this way, the payment method can accept orders within the merchant's mini-program through payment controls other than those provided by the owner of the main application, increasing payment options and improving payment efficiency.

[0150] The following is combined with Figure 5The payment method based on the resource payment server provided in the embodiments of this application will be described in detail.

[0151] Figure 5 This is a flowchart illustrating a payment method based on a resource payment server, as provided in an embodiment of this application.

[0152] like Figure 5 As shown, this payment method can be applied to, for example... Figure 1 The resource payment server in the payment architecture shown can specifically include the following steps:

[0153] Step 510: Receive a query request sent by the main application server; Step 520: Based on the query request, determine the query feedback result regarding whether an authorization relationship has been established between the application account and the payment account. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment functionality embedded in the main application; Step 530: Send the query feedback result to the main application server; Step 540: Upon receiving the first payment instruction sent by the main application, process the payment order through the payment account of the payment mini-program.

[0154] The above steps are explained in detail below:

[0155] First, regarding step 510, in one or more possible embodiments, the payment account of the payment mini-program is M payment accounts, where M is an integer greater than 1. Based on this, after step 510, the payment method may further include:

[0156] Send a fifth instruction to the main application server. The fifth instruction is used to instruct the main application server to prompt the user to select the target payment account from M payment accounts through the payment applet shown.

[0157] Upon receiving the target payment account specified by the user from the main application server, the system checks whether an authorization relationship has been established between the application account and the target payment account.

[0158] Secondly, regarding step 530, in one or more possible embodiments, the query feedback result carries a first information retrieval request. The query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship. The first information retrieval request is used to request the first communication device number bound to the application account. Based on this, after step 530, the payment method may further include:

[0159] Step 5501: Receive the first real-name matching request sent by the main application server. The first real-name matching request includes the first communication device number bound to the application account.

[0160] Step 5502: If the second communication device number bound to the payment account is obtained, determine whether the first communication device number and the second communication device number match according to the first real-name matching request;

[0161] Step 5503: If it is determined that the first communication device number and the second communication device number match, a second real-name matching request is sent to the main application server. The second real-name matching request includes the first matching result and the first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number and the second communication device number bound to the payment account match. The second real-name matching request is used to request the main application server to determine whether the first user identity credential is associated with the application account.

[0162] In one embodiment, after step 5503, the payment method may further include:

[0163] Receive the establishment notification sent by the main application server;

[0164] According to the notification, establish the authorization relationship between the application account and the payment account.

[0165] In another embodiment, after step 5502, the payment method may further include:

[0166] If it is determined that the first communication device number and the second communication device number do not match, a first instruction is sent to the main application server. The first instruction is used to instruct the main application to prompt the user to enter user identity credentials through the payment applet.

[0167] In yet another embodiment, prior to step 5503, the payment method may further include:

[0168] Determine if the payment account is verified with your real name;

[0169] If it is confirmed that the payment account has been verified with real name, the user identity credential that has been verified with real name for the payment account will be identified as the first user identity credential.

[0170] Conversely, if it is determined that the payment account is not real-name authenticated, a second instruction is sent to the main application server. The second instruction is used to instruct the main application to prompt the user to enter user identity credentials through the payment applet, and to determine whether to establish an authorization relationship between the application account and the payment account based on the target user identity credentials entered by the user.

[0171] In another embodiment, after step 5501, the payment method may further include:

[0172] If a second communication device number not bound to a payment account is obtained, a third instruction is sent to the main application server. The third instruction is used to instruct the main application to prompt the user to enter the user's communication device number through the payment applet.

[0173] Receive user communication device notifications sent by the main application server. The user communication device notifications include the target user communication device number entered by the user.

[0174] The target user's communication device number is determined as the second communication device number.

[0175] Based on this, the embodiments of this application can be illustrated by the following examples. Figure 4 and Figure 5 The content will be further explained below.

[0176] First, the payment mini-program in the main application is invoked to determine whether the payment mini-program's payment account has an authorization relationship with the application account of the main application.

[0177] If the payment account is authorized to the application account, the payment will be made through the payment mini-program.

[0178] If the payment account and the application account have not been authorized, you can perform the following steps.

[0179] If the first communication device number bound to the application account is already associated with the payment account, that is, if the first communication device number matches the second communication device number bound to the payment account, then it is further determined whether the payment account has been verified with a real name:

[0180] (1) The payment account has been verified with real name.

[0181] If the first user identity credential bound to the payment account matches the second user identity credential bound to the application account, the electronic device can be triggered to display the associated identity information page, and then the face verification page will be triggered to perform face verification. After the verification is successful, the binding relationship between the payment account and the application account will be established.

[0182] If the first user identity credential bound to the payment account is inconsistent with the second user identity credential bound to the application account, the electronic device ID card input page can be triggered. The user enters the user identity credential, and facial verification is performed after the entered target user identity credential matches the second user identity credential.

[0183] Here, after verification, if the number of associated payment accounts is 0, a payment account in the form of a username is created and associated with identity information, establishing a binding relationship between the application account and the payment account. If the number of associated payment accounts is more than 1, the user selects one of the payment accounts and establishes a binding relationship between the selected payment account and the application account.

[0184] (2) The payment account is not registered with the real name.

[0185] The system can trigger the display of an ID card input page on the electronic device. The user enters the target user's identity certificate. After the target user's identity certificate matches the second user's identity certificate, facial verification is performed. If the verification is successful, and the number of associated payment accounts is 0, a payment account in the form of a username is created and associated with the identity information, establishing a binding relationship between the application account and the payment account. If the number of associated payment accounts is more than 1, the user selects one of the payment accounts, and a binding relationship is established between the selected payment account and the application account.

[0186] If the first communication device number bound to the application account is not associated with a payment account (i.e., the first communication device number does not match the second communication device number bound to the payment account), an ID card number input page is triggered. The user enters the target user's identity credential. After the entered target user's identity credential matches the second user's identity credential, facial verification is performed. After successful verification, if the number of associated payment accounts is 0, a payment account in the form of a username is created and associated with the identity information, establishing a binding relationship between the application account and the payment account. If the number of associated payment accounts is more than 1, the user selects one of the payment accounts, and a binding relationship is established between the selected payment account and the application account.

[0187] It should be noted that, in one example, if the first communication device number matches the second communication device number, but the user identity credentials bound to the payment account and the user identity credentials bound to the application account are not the same, but the target user identity credentials entered by the user are the same as the user identity credentials bound to the application account, and there is no record in the payment mini-program, the resource payment server can create a payment account name for the user. For example, the rule for creating the username is the first communication device number + a random string. Based on this, the method may also include: receiving an identity credential matching notification sent by the main application server; generating account information for the payment account based on the identity credential matching notification and the first communication device number, the account information including the account name of the payment account.

[0188] In another example, on the account selection page, after the user selects an account and clicks OK, the association is successfully established, and the user is redirected to the next page.

[0189] In another example, for the first communication device number, when the real-name information document type corresponding to the payment mini-program is not an ID card, the real-name information is first verified with the main application. If the verification information is consistent, the main application will report an error to the user that the document type is not supported; if the verification information is inconsistent, the original user association process will continue and the user will be taken to the page where they manually enter their name and ID number.

[0190] In another example, for the real-name information comparison interface, the same openid is limited to a maximum of 1 request per second. If this frequency is exceeded, the user is prompted "The operation is too frequent, please wait a few seconds and try again".

[0191] In another example, if only one payment account is associated and that account is frozen, the first preset display method can be used, such as graying out and not being selectable, with different prompts displayed based on the freeze type. If multiple payment accounts are associated and all of them are frozen, the second preset display method can be used, such as graying out and not being selectable, with different prompts displayed based on the freeze type. If multiple payment accounts are associated, and some of them are frozen while others are normal, the third preset display method can be used, such as displaying two parts: normal accounts can be selected, while frozen accounts are grayed out and not selectable, with different prompts displayed based on the freeze type. Furthermore, the prompts corresponding to different abnormal states are as follows: Background Freeze - Cannot Unfreeze: "Payment account status is abnormal"; Background Freeze - Allow Unfreeze: "Payment account is frozen"; Payment Mini-Program Self-Service Freeze: "Payment account is frozen. To unfreeze, please use the payment application corresponding to the payment mini-program." Different freeze types can be distinguished based on the freeze type field (freezeTP) in the unified user database, with specific values ​​as follows: Payment Mini Program Freeze; Backend Freeze; (corresponding to Resource Payment Server Freeze - Allow Unfreezing) above; Violation Freeze (Cannot Unfreeze); (corresponding to Resource Payment Server Freeze - Cannot Unfreeze) above). In the association logic, if a user needs to create a new payment account on the resource payment server, it does not involve an abnormal state. If the user can only find one record that meets the association criteria in the backend, before association, it is determined whether the payment account status is normal. If normal, the association is successful; if abnormal, the account association page should be displayed, showing the reason for the abnormality. If the user finds multiple records that meet the association criteria in the backend, the account association page should be displayed, showing the results according to whether the account status is normal.

[0192] Then, relating to step 540, in one or more possible embodiments, this step may specifically include:

[0193] Upon receiving a first payment instruction from the main application, a first resource transfer request is sent to the resource management server. The first resource transfer request includes a payment order, which includes a first resource card bound to the payment account, the resource transfer amount for the payment order, and information about the payee's account. The first resource transfer request is used to request the resource management server to process the payment order based on the first resource card. In another or more possible embodiments, after step 540, the payment method may further include:

[0194] Step 5601: If it is determined that the payment account of the payment mini-program is not bound to a resource card, a fourth instruction is sent to the main application server. The fourth instruction is used to instruct the main application server to prompt the user to bind a resource card to the payment account through the payment mini-program.

[0195] Step 5602: Upon receiving the information of the first resource card sent by the main application server, a card binding request is sent to the resource management server. The card binding request includes the information of the first resource card, authorization code, authorization interface credential, user identity identifier (such as OpenID), and user authorization information. The card binding request is used to request the resource management server to bind the payment account and the first resource card according to the authorization code, authorization interface credential, user identity identifier, and user authorization information.

[0196] Step 5603: Upon receiving the binding completion result from the resource management server, a third resource transfer request is sent to the resource management server. The third resource transfer request includes a payment order, which includes the first resource card, the resource transfer amount of the payment order, and the information of the payee's account. The third resource transfer request is used to request the resource management server to process the payment order based on the first resource card.

[0197] For example, such as Figure 6 As shown, the process of binding resource cards can be based on the resource payment server and the resource management server, as detailed below:

[0198] S601, if the payment account is not bound to a resource card or needs to be bound to a resource card, the electronic device receives the user's input to enter the card addition page by clicking "Add Resource Card" and the input to select the resource management server from the resource card list. Based on the above two inputs, the electronic device sends user information to the resource management server through the authorized payment mini-program. The user information includes the user's identity certificate, communication device number, etc.

[0199] S602, the resource payment server sends the generated authorization code to the resource management server.

[0200] S603, the resource management server sends a code back to the resource payment server;

[0201] S604, the resource payment server sends a card binding request to the resource management server. The card binding request includes an access token and a user ID.

[0202] S605, upon receiving a card binding request, the resource management server sends a second information acquisition request to the resource payment server. The second information acquisition request is used to acquire user information.

[0203] S606, The resource payment server sends the user information authorized by the user to the resource management server based on the second information acquisition request;

[0204] S607, the resource management server displays a list of resource cards associated with the user on the resource payment server in the resource management server H5 page based on the user information, and determines the resource card bound to the user.

[0205] S608, the resource management server sends the user-bound resource card information to the resource payment server through the card binding interface;

[0206] S609, the resource payment server sends an SN number to the resource management server. The SN number is used as an input parameter for the front-end to jump to the resource payment server.

[0207] S610, the resource management server accesses the online payment activation page of the resource payment server based on the SN number;

[0208] S611, the resource payment server redirects to the online payment activation page via the payment mini-program, so that after the user completes the online payment activation verification and SMS verification, the system synchronously completes the card binding process, and then directly triggers the subsequent payment or payment password setting process.

[0209] It should be noted that the process of setting a payment password may result in the following situations, which are explained below. If a user has completed binding a resource card but has not set a payment password, the resource payment server will prompt the user to enter a payment password through the payment mini-program. During the payment password input process, the following possibilities may occur: If the new payment password is the same as the original password, the user will be prompted to reset the payment password; if the new payment password is not a repeated or consecutive number, the user will be prompted to reset the payment password; if the new payment password includes at least the target number, the user will be prompted to reset the payment password. The target number includes at least one of the following: at least partially consecutive numbers in the user's communication device number, or at least partially consecutive numbers in the user's ID card number.

[0210] And, further, such as Figure 7As shown, the resource payment server can specifically include an omnichannel system and a resource payment management system. Based on the specific system of the resource payment server, the following process of binding resource cards can be executed.

[0211] like Figure 7 As shown, in one or more possible embodiments, after S601 described above, the resource payment server may specifically perform the following steps:

[0212] S701, the omnichannel system sends a request to the resource payment management system, requesting the API interface of the resource management server of each resource card in the supported resource card list;

[0213] S702, the resource payment management system returns information about the resource management service that supports binding resource cards to the omnichannel system, such as the resource management service name, resource management service organization number, and resource card type;

[0214] S703, the omnichannel system sends user information to the resource payment management system, which may include user identity credentials, communication device number, etc.

[0215] S704, the resource payment management system sends the SN number to the omnichannel system. The SN number is used as a parameter to redirect the front-end to the UnionPay page. It is valid only once and lasts for 5 minutes.

[0216] In addition, the resource payment management system can also send user identity identifiers, payment accounts associated with payment mini-programs, and other information used in this application embodiment to establish the authorization relationship between application accounts and payment accounts to the omnichannel system.

[0217] Therefore, users can... Figure 6 and Figure 7 The instructions show that users can bind one resource card at a time. Users can log in to the payment mini-program, select the one-click card binding function, then choose a resource management server that supports binding the resource card, and authorize it. This involves the payment mini-program sending user information such as name, ID number, and ID type to the resource payment server backend to complete the resource card binding and activate online payment. Alternatively, users can be prompted to bind multiple resource cards at once using the same method, and can complete the binding and online payment activation process in the same way. Further details are omitted here.

[0218] The following is combined with Figure 8 The payment method based on electronic devices provided in the embodiments of this application will be described in detail.

[0219] Figure 8 A flowchart illustrating a payment method based on an electronic device, as provided in this application embodiment.

[0220] like Figure 8 As shown, this payment method can be applied to, for example... Figure 1 The payment method in the illustrated payment architecture may specifically include the following steps:

[0221] Step 810: Display the first interface of the merchant mini-program in the main application;

[0222] Step 820: Upon receiving the first input to the first interface, switch the display from the first interface to the second interface. The first input is an input confirming the submission of a payment order in the merchant mini-program. The second interface is the interface for the payment mini-program to process the payment order. The payment mini-program is an application with payment function embedded in the main application.

[0223] Step 830: If it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, display the payment result after the payment mini-program has processed the payment order.

[0224] Therefore, as Figure 9 As shown, the first interface 90 of the merchant mini-program in the main application is displayed. When the first input to the first interface is received, such as the user clicking "Buy Now", the interface switches to the second interface 91 to allow the user to verify the payment content. Then, if the user clicks "Confirm Payment" and the payment account and the application account have established an authorization relationship, the payment result after the payment mini-program has processed the payment order is displayed.

[0225] In this way, the payment function provided by the resource payment server can be integrated into the main application as a mini-program, so that there is no need to jump to other third-party applications, and the fast payment service can be realized directly within the main application.

[0226] In addition, the application scenario can also be used for offline QR code payment. Based on this, the following will combine... Figure 10 The payment method based on electronic devices provided in the embodiments of this application will be described in detail.

[0227] Figure 10 A flowchart illustrating a payment method based on an electronic device, as provided in this application embodiment.

[0228] like Figure 10 As shown, this payment method can be applied to, for example... Figure 1 The payment method in the illustrated payment architecture may specifically include the following steps:

[0229] Step 1010: Display the third interface of the main application. The third interface includes N payers, where N is an integer greater than 1.

[0230] Step 1020: Upon receiving the user's third input for the target payer among N payers, the interface switches from the third interface to the fourth interface. The fourth interface is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment function embedded in the main application. The payment interface includes the payment code provided by the payment mini-program.

[0231] Step 1030: If it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the fifth interface is displayed. The fifth interface includes the payment result after the payment mini-program processes the payment order; the owner of the payment mini-program is different from the owner of the main application.

[0232] like Figure 11 As shown, the third interface 110 of the main application is displayed. The third interface 110 includes three payers, such as payer 1, payer 2, and payer 3. Upon receiving a third input from the user for payer 3, the display switches from the third interface 110 to the fourth interface 111. Here, the fourth interface 111 is the payment interface of the payment mini-program corresponding to payer 3. The payment interface may include a payment code provided by the payment mini-program for scanning by the receiving device. After confirming that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the fifth interface 112 is displayed.

[0233] Thus, the payment method provided in this application embodiment can be applied not only to remote mobile payment scenarios, but also to near-field mobile payments, i.e., displaying a payment code to the receiving device. It can also be implemented in the main application by integrating the payment function provided by the resource payment server corresponding to the payer into the main application in the form of a mini-program, so that there is no need to jump to other third-party applications, and fast payment services can be realized directly within the main application.

[0234] Based on the same inventive concept, this application also provides a payment device. (Specifically combined with...) Figure 12 Please provide a detailed explanation.

[0235] Figure 12 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application.

[0236] In some embodiments of this application, Figure 12 The payment device shown can be set up in, for example Figure 1 The main application server is shown.

[0237] like Figure 12 As shown, the payment device 120 may specifically include:

[0238] The receiving module 1201 is used to receive payment orders from the merchant's mini-program in the main application;

[0239] The sending module 1202 is used to send a query request to the resource payment server corresponding to the payment mini-program according to the payment order. The query request is used to request the resource payment server to determine whether the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The payment mini-program is an application with payment function embedded in the main application.

[0240] The receiving module 1201 is also used to receive the query feedback results sent by the resource payment server;

[0241] The sending module 1202 is also used to send a first payment instruction to the resource payment server when the query feedback result indicates that the application account and the payment account have established an authorization relationship. The first payment instruction is used to instruct the payment mini-program to process the payment order.

[0242] The payment device 120 in the embodiments of this application will be described in detail below.

[0243] In one or more optional embodiments, the payment device 120 in this application embodiment may further include a first determining module; wherein,

[0244] The sending module 1202 is further configured to, when the query feedback result carries a first information acquisition request, the query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship, and the first information acquisition request is used to request the first communication device number bound to the application account, send a first real-name matching request to the resource payment server according to the first information acquisition request; wherein, the first real-name matching request includes the first communication device number bound to the application account, and the first real-name matching request is used to request to determine whether the first communication device number is associated with the payment account;

[0245] The receiving module 1201 can also be used to receive a second real-name matching request sent by the resource payment server. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number matches the second communication device number bound to the payment account.

[0246] The first determining module is used to determine whether the first user identity credential and the second user identity credential match when a second user identity credential bound to the application account is obtained.

[0247] The sending module 1202 is also used to send an establishment notification to the resource payment server when the first user identity credential and the second user identity credential match. The establishment notification is used to notify the resource payment server to establish an authorization relationship between the application account and the payment account.

[0248] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a first prompt module and a first matching module; wherein,

[0249] The receiving module 1201 is also used to receive the first instruction sent by the resource payment server;

[0250] The first prompt module is used to prompt the user to enter their identity credentials via the payment mini-program based on the first instruction.

[0251] The first matching module is used to match the target user identity credential with the second user identity credential bound to the application account when the target user identity credential is received by the user.

[0252] The first prompt module can also be used to prompt the user to extract biometric features through the payment mini-program when the target user's identity certificate and the second user's identity certificate match.

[0253] The sending module 1202 is also used to send an establishment notification to the resource payment server when it obtains the user's target biometric information and the target biometric information matches the preset biometric information.

[0254] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a second prompting module; wherein,

[0255] The second prompt module is used to prompt the user to extract biometric features via the payment mini-program when the first user identity certificate and the second user identity certificate match.

[0256] The sending module 1202 is also used to send an establishment notification to the resource payment server when it obtains the user's target biometric information and the target biometric information matches the preset biometric information.

[0257] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a third prompting module and a second matching module; wherein,

[0258] The third prompt module is used to prompt the user to enter their user identity credentials via the payment mini-program when the first user identity credentials and the second user identity credentials do not match.

[0259] The second matching module is used to match the target user identity credential with the second user identity credential bound to the application account when the target user identity credential is received by the user.

[0260] The third prompt module is also used to prompt the user to extract biometric features through the payment mini-program when the target user's identity certificate and the second user's identity certificate match.

[0261] The sending module 1202 is also used to send an establishment notification to the resource payment server when it obtains the user's target biometric information and the target biometric information matches the preset biometric information.

[0262] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a fourth prompting module and a third matching module; wherein,

[0263] The receiving module 1201 is also used to receive a second instruction sent by the resource payment server;

[0264] The fourth prompt module is used to prompt the user to enter their identity credentials via the payment mini-program, based on the second instruction.

[0265] The third matching module is used to match the target user identity credential with the second user identity credential bound to the application account when the target user identity credential is received by the user.

[0266] The fourth prompt module is also used to prompt the user to extract biometric features through the payment mini-program when the target user's identity credentials match the second user's identity credentials.

[0267] The sending module 1202 is also used to send an establishment notification to the resource payment server when it obtains the user's target biometric information and the target biometric information matches the preset biometric information.

[0268] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a fifth prompting module; wherein,

[0269] The receiving module 1201 is also used to receive a third instruction sent by the resource payment server;

[0270] According to the third instruction, the user is prompted to enter their communication device number via the payment mini-program;

[0271] The sending module 1202 is also used to send a user communication device notification to the resource payment server when it receives the target user communication device number input by the user. The user communication device notification includes the target user communication device number and is used to notify the resource payment server to identify the target user communication device number as the second communication device number bound to the payment account.

[0272] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a sixth prompt module; wherein,

[0273] The receiving module 1201 is also used to receive a fourth instruction sent by the resource payment server;

[0274] The sixth prompt module is used to prompt the user to bind a resource card to the payment account via the payment mini-program, based on the fourth instruction.

[0275] The sending module 1202 is also used to send information about the first resource card to the resource payment server when it receives user input that the first resource card is bound to the payment account.

[0276] In another or more alternative embodiments, the payment device 120 in this application embodiment may further include a seventh prompt module; wherein,

[0277] The receiving module 1201 is also used to receive the fifth instruction sent by the resource payment server when the payment account of the payment mini-program is M payment accounts, where M is an integer greater than 1.

[0278] The seventh prompt module is used to prompt the user to select the target payment account from M payment accounts according to the fifth instruction and through the payment applet shown. The target payment account is the payment account that establishes an authorization relationship with the application account.

[0279] The sending module 1202 is also used to send the target payment account determined by the user to the resource payment server, so that the resource payment server can provide feedback on whether the application account of the main application and the target payment account have established an authorization relationship.

[0280] In another or more alternative embodiments, the receiving module 1201 is further configured to receive an abnormal instruction sent by the resource payment server, wherein the abnormal instruction indicates that the account status of the payment account and / or the status of the resource card bound to the payment account is a preset abnormal status.

[0281] The sending module 1202 is also used to send a second resource transfer request to the resource management server according to the abnormal instruction. The second resource transfer request includes a payment order, which includes a second resource card bound to the application account, the resource transfer amount of the payment order, and the information of the payee's account. The second resource transfer request is used to request the resource management server to process the payment order according to the second resource card.

[0282] In another or more alternative embodiments, the owner of the payment mini-program is different from the owner of the main application.

[0283] Based on the same inventive concept, this application also provides a payment device. (Specifically combined with...) Figure 13 Please provide a detailed explanation.

[0284] Figure 13 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application.

[0285] In some embodiments of this application, Figure 13 The payment device shown can be set up in, for example Figure 1 The resource payment service shown.

[0286] like Figure 13 As shown, the payment device 130 may specifically include:

[0287] The receiving module 1301 is used to receive query requests sent by the main application server;

[0288] The determination module 1302 is used to determine the query feedback result of whether the application account and the payment account have established an authorization relationship based on the query request. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment function embedded in the main application.

[0289] The sending module 1303 is used to send query feedback results to the main application server.

[0290] The processing module 1304 is used to process the payment order through the payment account of the payment mini-program upon receiving the first payment instruction sent by the main application.

[0291] The payment device 130 in the embodiments of this application will be described in detail below.

[0292] In one or more optional embodiments, the receiving module 1301 may also be used to receive a first real-name matching request sent by the main application server when the query feedback result carries a first information acquisition request, the query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship, and the first information acquisition request is used to request the first communication device number bound to the application account. The first real-name matching request includes the first communication device number bound to the application account.

[0293] The determining module 1302 can also be used to determine whether the first communication device number and the second communication device number match based on the first real-name matching request, when the second communication device number bound to the payment account is obtained.

[0294] The sending module 1303 can also be used to send a second real-name matching request to the main application server when it is determined that the first communication device number and the second communication device number match. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number and the second communication device number bound to the payment account match. The second real-name matching request is used to request the main application server to determine whether the first user identity credential is associated with the application account.

[0295] In another or more alternative embodiments, the payment device 130 in this application embodiment may further include a first establishment module; wherein,

[0296] The receiving module 1301 can also be used to receive the establishment notification sent by the main application server;

[0297] The first module is used to establish the authorization relationship between the application account and the payment account based on the establishment notification.

[0298] In another or more alternative embodiments, the sending module 1303 may also be used to send a first instruction to the main application server when it is determined that the first communication device number and the second communication device number do not match. The first instruction is used to instruct the main application to prompt the user to enter user identity credentials through the payment applet.

[0299] In another or more alternative embodiments, the determining module 1302 may also be used to determine whether the payment account is real-name authenticated;

[0300] The determination module 1302 can also be used to determine the user identity credential that has been verified with the real name of the payment account as the first user identity credential, provided that the payment account has been verified with the real name.

[0301] In another or more alternative embodiments, the sending module 1303 may also be used to send a second instruction to the main application server when it is determined that the payment account has not been real-name authenticated. The second instruction is used to instruct the main application to prompt the user to enter the user identity credential through the payment applet, and to determine whether to establish an authorization relationship between the application account and the payment account based on the target user identity credential entered by the user.

[0302] In another or more alternative embodiments, the sending module 1303 may also be used to send a third instruction to the main application server when a second communication device number not bound to the payment account is obtained. The third instruction is used to instruct the main application to prompt the user to enter the user's communication device number through the payment applet.

[0303] The receiving module 1301 can also be used to receive a user communication device notification sent by the main application server, wherein the user communication device notification includes the target user communication device number input by the user.

[0304] The determination module 1302 can also be used to determine the target user's communication device number as the second communication device number.

[0305] In another or more alternative embodiments, the sending module 1303 may also be used to send a fourth instruction to the main application server when it is determined that the payment account of the payment mini-program is not bound to a resource card. The fourth instruction is used to instruct the main application server to prompt the user to bind a resource card to the payment account through the payment mini-program.

[0306] The sending module 1303 can also be used to send a card binding request to the resource management server when it receives the information of the first resource card sent by the main application server. The card binding request includes the information of the first resource card, the authorization code, the authorization interface credential, the user identity identifier and the user authorization information. The card binding request is used to request the resource management server to bind the payment account and the first resource card according to the authorization code, the authorization interface credential, the user identity identifier and the user authorization information.

[0307] The sending module 1303 can also be used to send a third resource transfer request to the resource management server when it receives the binding completion result sent by the resource management server. The third resource transfer request includes a payment order, which includes the first resource card, the resource transfer amount of the payment order, and the information of the payee's account. The third resource transfer request is used to request the resource management server to process the payment order according to the first resource card.

[0308] In another or more alternative embodiments, the sending module 1303 is further configured to send a fifth instruction to the main application server when the payment account of the payment mini-program is M payment accounts, where M is an integer greater than 1. The fifth instruction is configured to instruct the main application server to prompt the user to determine the target payment account from the M payment accounts through the payment mini-program.

[0309] The determination module 1302 can also be used to determine, upon receiving a target payment account determined by the user from the main application server, whether an authorization relationship has been established between the application account and the target payment account.

[0310] In another or more alternative embodiments, the sending module 1303 may be specifically used to send a first resource transfer request to the resource management server upon receiving a first payment instruction sent by the main application. The first resource transfer request includes a payment order, which includes a first resource card bound to the payment account, the resource transfer amount of the payment order, and information of the payee's account. The first resource transfer request is used to request the resource management server to process the payment order based on the first resource card.

[0311] Based on the same inventive concept, this application also provides a payment device. (Specifically combined with...) Figure 14 Please provide a detailed explanation.

[0312] Figure 14 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application.

[0313] In some embodiments of this application, Figure 14 The payment device shown can be set up in, for example Figure 1 In the electronic device shown.

[0314] like Figure 14 As shown, the payment device 140 may specifically include:

[0315] Display module 1401 is used to display the first interface of the merchant mini-program in the main application;

[0316] The display module 1401 is also used to switch the display from the first interface to the second interface when a first input is received on the first interface, wherein the first input is an input to confirm the submission of a payment order in the merchant mini-program, and the second interface is the interface for the payment mini-program to process the payment order, and the payment mini-program is an application with payment function embedded in the main application.

[0317] The display module 1401 is also used to display the payment result of the payment order processed by the payment mini-program when it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship.

[0318] Based on the same inventive concept, this application also provides a payment device. (Specifically combined with...) Figure 15 Please provide a detailed explanation.

[0319] Figure 15 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application.

[0320] In some embodiments of this application, Figure 15 The payment device shown can be set up in, for example Figure 1 In the electronic device shown.

[0321] like Figure 15 As shown, the payment device 150 may specifically include:

[0322] Display module 1501 is used to display the third interface of the main application. The third interface includes N payers, where N is an integer greater than 1.

[0323] The display module 1501 is also used to switch from the third interface to the fourth interface when the user receives the third input of the target payer among N payers. The fourth interface is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment function embedded in the main application. The payment interface includes the payment code provided by the payment mini-program.

[0324] The display module 1501 is also used to display a fifth interface when it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The fifth interface includes the payment result after the payment mini-program processes the payment order; the owner of the payment mini-program is different from the owner of the main application.

[0325] Therefore, the main application server can send a query request to the resource payment server corresponding to the payment mini-program based on the payment order from the merchant mini-program within the main application. The query request is used to ask the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The payment mini-program is an application with payment functionality embedded in the main application. Then, upon receiving the query feedback result from the resource payment server indicating that an authorization relationship has been established between the application account and the payment account, a first payment instruction can be sent to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. Thus, this payment method can pay for orders in the merchant mini-program through payment methods other than those provided by the main application provider, increasing payment channels and improving payment efficiency. Furthermore, paying for orders in the merchant mini-program within the payment mini-program of the main application does not require redirection to pages outside the main application, such as HTML5 pages, nor does it require redirection to a third-party payment application to complete the payment, reducing the user's operations of triggering the launch of a third-party application and returning to the main application, thereby improving the convenience of user payments.

[0326] Based on the same inventive concept, this application also provides a payment device. (Specifically combined with...) Figure 16 Please provide a detailed explanation.

[0327] Figure 16 This is a schematic diagram of the structure of a payment device provided in one embodiment of this application.

[0328] like Figure 16As shown, the payment device may include at least one of the following as described in the embodiments of this application: an electronic device, a server. The payment device may include a processor 1601 and a memory 1602 storing computer program instructions.

[0329] Specifically, the processor 1601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0330] Memory 1602 may include mass storage for data or instructions. For example, and not limitingly, memory 1602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1602 may include removable or non-removable (or fixed) media. Where appropriate, memory 1602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1602 is non-volatile solid-state memory. In a particular embodiment, memory 1602 includes solid-state storage (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0331] The processor 1601 implements any of the payment methods described in the above embodiments by reading and executing computer program instructions stored in the memory 1602.

[0332] In one example, the payment device may also include a communication interface 1603 and a bus 1610. For example, Figure 16 As shown, the processor 1601, memory 1602, and communication interface 1603 are connected through bus 1610 and complete communication with each other.

[0333] The communication interface 1603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0334] Bus 1610 includes hardware, software, or both, that couples components of a flow control device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0335] The data processing device can execute the payment method in the embodiments of this application, thereby achieving a combination Figures 1 to 11 The payment methods and devices described.

[0336] Furthermore, in conjunction with the payment methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the payment methods in the above embodiments.

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

[0338] The functional blocks shown in the above 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 this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

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

[0340] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A payment method applied to a main application server, comprising: Receive payment orders from merchant mini-programs within the main application; Based on the payment order, a query request is sent to the resource payment server corresponding to the payment mini-program. The query request is used to request the resource payment server to determine whether the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The payment mini-program is an application with payment function embedded in the main application, and the owner of the payment mini-program is different from the owner of the main application. Receive the query feedback results sent by the resource payment server; If the query feedback result indicates that the application account and the payment account have established an authorization relationship, a first payment instruction is sent to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. If the first communication device number bound to the application account matches the second communication device number bound to the payment account, and the first user identity credential bound to the payment account matches the second user identity credential bound to the application account, then the application account and the payment account have established an authorization relationship.

2. The method according to claim 1, characterized in that, The query feedback result carries a first information acquisition request. The query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship. The first information acquisition request is used to request the first communication device number bound to the application account. After receiving the query feedback result sent by the resource payment server, the method further includes: Based on the first information acquisition request, a first real-name matching request is sent to the resource payment server; wherein, the first real-name matching request includes a first communication device number bound to the application account, and the first real-name matching request is used to request to determine whether the first communication device number is associated with the payment account; The system receives a second real-name matching request sent by the resource payment server. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number and the second communication device number bound to the payment account match. If a second user identity credential bound to the application account is obtained, it is determined whether the first user identity credential and the second user identity credential match. If the first user identity credential and the second user identity credential match, a notification is sent to the resource payment server to establish an authorization relationship between the application account and the payment account.

3. The method according to claim 2, characterized in that, After sending the first real-name matching request to the resource payment server, the method further includes: Receive the first instruction sent by the resource payment server; According to the first instruction, the user is prompted to enter their identity credentials through the payment mini-program; Upon receiving the target user identity credential input by the user, the target user identity credential is matched with the second user identity credential bound to the application account; If the target user's identity credential matches the second user's identity credential, the user will be prompted to extract biometric features via the payment mini-program. Upon obtaining the user's target biometric information and finding that the target biometric information matches a preset biometric feature, the establishment notification is sent to the resource payment server.

4. The method according to claim 2, characterized in that, If the first user identity credential and the second user identity credential match, a notification is sent to the resource payment server, including: If the first user identity credential and the second user identity credential match, the user will be prompted to extract biometric features through the payment mini-program; Upon obtaining the user's target biometric information and finding that the target biometric information matches a preset biometric feature, the establishment notification is sent to the resource payment server.

5. The method according to claim 2, characterized in that, After determining whether the first user identity credential and the second user identity credential match, the method further includes: If the first user identity credential and the second user identity credential do not match, the user will be prompted to enter a user identity credential through the payment mini-program; Upon receiving the target user identity credential input by the user, the target user identity credential is matched with the second user identity credential bound to the application account; If the target user's identity credential matches the second user's identity credential, the user will be prompted to extract biometric features through the payment mini-program. Upon obtaining the user's target biometric information and finding that the target biometric information matches a preset biometric feature, the establishment notification is sent to the resource payment server.

6. The method according to claim 2, characterized in that, After sending the first real-name matching request to the resource payment server, the method further includes: Receive the second instruction sent by the resource payment server; According to the second instruction, the user is prompted to enter their identity credentials through the payment mini-program; Upon receiving the target user identity credential input by the user, the target user identity credential is matched with the second user identity credential bound to the application account; If the target user's identity credential matches the second user's identity credential, the user will be prompted to extract biometric features via the payment mini-program. Upon obtaining the user's target biometric information and finding that the target biometric information matches a preset biometric feature, the establishment notification is sent to the resource payment server.

7. The method according to claim 2, characterized in that, Before receiving the second real-name matching request sent by the resource payment server, the method further includes: Receive the third instruction sent by the resource payment server; According to the third instruction, the user is prompted to enter their communication device number through the payment mini-program; Upon receiving the target user communication device number input by the user, a user communication device notification is sent to the resource payment server. The user communication device notification includes the target user communication device number and is used to notify the resource payment server to identify the target user communication device number as the second communication device number bound to the payment account.

8. The method according to claim 1, characterized in that, After sending the first payment instruction to the resource payment server, the method further includes: Receive the fourth instruction sent by the resource payment server; According to the fourth instruction, the user is prompted to bind a resource card to the payment account via the payment mini-program; Upon receiving user input that the first resource card is bound to the payment account, the system sends the information of the first resource card to the resource payment server.

9. The method according to claim 1, characterized in that, The payment mini-program has M payment accounts, where M is an integer greater than 1; before receiving the query feedback result sent by the resource payment server, the method further includes: Receive the fifth instruction sent by the resource payment server; According to the fifth instruction, the user is prompted to select a target payment account from the M payment accounts through the payment mini-program shown. The target payment account is the payment account that has established an authorization relationship with the application account. The target payment account specified by the user is sent to the resource payment server so that the resource payment server can provide a query result indicating whether an authorization relationship has been established between the application account of the main application and the target payment account.

10. The method according to claim 1, characterized in that, The method further includes: Receive an abnormal instruction sent by the resource payment server, the abnormal instruction being used to indicate that the account status of the payment account and / or the status of the resource card bound to the payment account is a preset abnormal status; According to the abnormal instruction, a second resource transfer request is sent to the resource management server. The second resource transfer request includes the payment order, which includes the second resource card bound to the application account, the resource transfer amount of the payment order, and the information of the payee account. The second resource transfer request is used to request the resource management server to process the payment order according to the second resource card.

11. A payment method applied to a resource payment server, comprising: Receive query requests sent by the main application server; Based on the query request, the query feedback result determines whether an authorization relationship has been established between the application account and the payment account. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment function embedded in the main application. The owner of the payment mini-program is different from the owner of the main application. If the first communication device number bound to the application account matches the second communication device number bound to the payment account, and the first user identity credential bound to the payment account matches the second user identity credential bound to the application account, then an authorization relationship has been established between the application account and the payment account. The query feedback result is sent to the main application server; Upon receiving the first payment instruction sent by the main application, the payment order is processed through the payment account of the payment mini-program.

12. The method according to claim 11, characterized in that, The query feedback result carries a first information acquisition request. The query feedback result is used to indicate that the application account and the payment account have not established an authorization relationship. The first information acquisition request is used to request the first communication device number bound to the application account. After sending the query feedback result to the main application server, the method further includes: Receive a first real-name matching request sent by the main application server, wherein the first real-name matching request includes a first communication device number bound to the application account; If the second communication device number bound to the payment account is obtained, it is determined whether the first communication device number and the second communication device number match according to the first real-name matching request; If the first communication device number and the second communication device number are determined to match, a second real-name matching request is sent to the main application server. The second real-name matching request includes a first matching result and a first user identity credential bound to the payment account. The first matching result is used to indicate that the first communication device number and the second communication device number bound to the payment account match. The second real-name matching request is used to request the main application server to determine whether the first user identity credential is associated with the application account.

13. The method according to claim 12, characterized in that, After sending the second real-name matching request to the main application server, the method further includes: Receive the establishment notification sent by the main application server; According to the establishment notification, the authorization relationship between the application account and the payment account is established.

14. The method according to claim 12, characterized in that, After determining whether the first communication device number and the second communication device number match, the method further includes: If it is determined that the first communication device number and the second communication device number do not match, a first instruction is sent to the main application server. The first instruction is used to instruct the main application to prompt the user to enter user identity credentials through the payment applet.

15. The method according to claim 12, characterized in that, Before sending the second real-name matching request to the main application server, the method further includes: Determine whether the payment account is real-name authenticated; If it is determined that the payment account has been verified with real name, the user identity credential that has been verified with real name for the payment account will be identified as the first user identity credential.

16. The method according to claim 13, characterized in that, The method further includes: If it is determined that the payment account is not real-name authenticated, a second instruction is sent to the main application server. The second instruction is used to instruct the main application to prompt the user to enter user identity credentials through the payment applet, and to determine whether to establish an authorization relationship between the application account and the payment account based on the target user identity credentials entered by the user.

17. The method according to claim 12, characterized in that, The method further includes: If a second communication device number not bound to the payment account is obtained, a third instruction is sent to the main application server. The third instruction is used to instruct the main application to prompt the user to enter the user's communication device number through the payment applet. Receive a user communication device notification sent by the main application server, wherein the user communication device notification includes the target user communication device number input by the user; The target user's communication device number is determined as the second communication device number.

18. The method according to claim 11, characterized in that, The method further includes: If it is determined that the payment account of the payment mini-program is not bound to a resource card, a fourth instruction is sent to the main application server. The fourth instruction is used to instruct the main application server to prompt the user to bind a resource card to the payment account through the payment mini-program. Upon receiving information about the first resource card sent by the main application server, a card binding request is sent to the resource management server. The card binding request includes information about the first resource card, an authorization code, an authorization interface credential, a user identity identifier, and user authorization information. The card binding request is used to request the resource management server to bind the payment account and the first resource card according to the authorization code, authorization interface credential, user identity identifier, and user authorization information. Upon receiving the binding completion result from the resource management server, a third resource transfer request is sent to the resource management server. The third resource transfer request includes the payment order, which includes the first resource card, the resource transfer amount of the payment order, and the information of the payee's account. The third resource transfer request is used to request the resource management server to process the payment order based on the first resource card.

19. The method according to claim 11, characterized in that, The payment mini-program has M payment accounts, where M is an integer greater than 1; the method further includes: Send a fifth instruction to the main application server, the fifth instruction being used to instruct the main application server to prompt the user to select the target payment account from the M payment accounts through the shown payment mini-program; Upon receiving the target payment account specified by the user from the main application server, the system checks whether an authorization relationship has been established between the application account and the target payment account.

20. The method according to claim 11, characterized in that, Upon receiving the first payment instruction sent by the main application, processing the payment order through the payment account of the payment mini-program includes: Upon receiving the first payment instruction sent by the main application, a first resource transfer request is sent to the resource management server. The first resource transfer request includes the payment order, which includes the first resource card bound to the payment account, the resource transfer amount of the payment order, and the information of the payee's account. The first resource transfer request is used to request the resource management server to process the payment order based on the first resource card.

21. A payment method applied to an electronic device, comprising: Displays the first interface of the merchant's mini-program in the main application; Upon receiving a first input to the first interface, the system switches to display a second interface. The first input is a confirmation of submitting a payment order in the merchant's mini-program. The second interface is where the payment mini-program processes the payment order. The payment mini-program is an application with payment functionality embedded in the main application, and its owner is different from that of the main application. Based on the payment order, the main application server sends a query request to the resource payment server corresponding to the payment mini-program. This query request requests the resource payment server to determine whether an authorization relationship exists between the application account of the main application and the payment account of the payment mini-program. If it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the main application server sends a first payment instruction to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. The payment result of the payment order processed by the payment mini-program is displayed. If the first communication device number bound to the application account and the second communication device number bound to the payment account match, and the first user identity credential bound to the payment account and the second user identity credential bound to the application account match, then the application account and the payment account have established an authorization relationship.

22. A payment method applied to an electronic device, comprising: The third interface of the main application is displayed, which includes N payers, where N is an integer greater than 1; Upon receiving a third input from the user regarding the target payer among the N payers, the interface switches from the third interface to a fourth interface. This fourth interface is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment functionality embedded within the main application. The payment interface includes a payment code provided by the payment mini-program. The ownership of the payment mini-program differs from that of the main application. Based on the payment order, the main application server sends a query request to the resource payment server corresponding to the payment mini-program. This query request requests the resource payment server to determine whether an authorization relationship exists between the application account of the main application and the payment account of the payment mini-program. If it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, the main application server sends a first payment instruction to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. The fifth interface is displayed, which includes the payment result after the payment mini-program processes the payment order; if the first communication device number bound to the application account and the second communication device number bound to the payment account match, and the first user identity credential bound to the payment account and the second user identity credential bound to the application account match, then the application account and the payment account have established an authorization relationship.

23. A payment device, applied to a main application server, the device comprising: The receiving module is used to receive payment orders from merchant mini-programs in the main application; The sending module is used to send a query request to the resource payment server corresponding to the payment mini-program based on the payment order. The query request is used to request the resource payment server to determine whether the application account of the main application and the payment account of the payment mini-program have established an authorization relationship. The payment mini-program is an application with payment function embedded in the main application, and the owner of the payment mini-program is different from the owner of the main application. The receiving module is also used to receive the query feedback results sent by the resource payment server; The sending module is further configured to, when the query feedback result indicates that the application account and the payment account have established an authorization relationship, send a first payment instruction to the resource payment server. The first payment instruction is used to instruct the payment mini-program to process the payment order. If the first communication device number bound to the application account matches the second communication device number bound to the payment account, and the first user identity credential bound to the payment account matches the second user identity credential bound to the application account, then the application account and the payment account have established an authorization relationship.

24. A payment device, applied to a resource payment server, the device comprising: The receiving module is used to receive query requests sent by the main application server; The determination module is used to determine the query feedback result of whether an authorization relationship has been established between an application account and a payment account based on the query request. The application account is the account of the main application corresponding to the main application server, and the payment account is the account of the payment mini-program corresponding to the resource payment server. The payment mini-program is an application with payment function embedded in the main application. The owner of the payment mini-program is different from the owner of the main application. If the first communication device number bound to the application account matches the second communication device number bound to the payment account, and the first user identity credential bound to the payment account matches the second user identity credential bound to the application account, then the application account and the payment account have established an authorization relationship. The sending module is used to send the query feedback result to the main application server; The processing module is used to process the payment order through the payment account of the payment mini-program upon receiving the first payment instruction sent by the main application.

25. A payment device applied to an electronic device, comprising: The display module is used to display the first interface of the merchant's mini-program in the main application. The display module is further configured to, upon receiving a first input to the first interface, switch the display from the first interface to a second interface, wherein the first input is an input confirming the submission of a payment order in the merchant mini-program, the second interface is an interface for the payment mini-program to process the payment order, the payment mini-program is an application with payment functionality embedded in the main application, and the owner of the payment mini-program is different from the owner of the main application; the main application server sends a query request to the resource payment server corresponding to the payment mini-program based on the payment order, the query request being used to request the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program; The display module is further configured to, when it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, send a first payment instruction to the resource payment server, wherein the first payment instruction is used to instruct the payment mini-program to process the payment order; The payment result of the payment order processed by the payment mini-program is displayed. If the first communication device number bound to the application account and the second communication device number bound to the payment account match, and the first user identity credential bound to the payment account and the second user identity credential bound to the application account match, then the application account and the payment account have established an authorization relationship.

26. A payment device applied to an electronic device, comprising: The display module is used to display the third interface of the main application, which includes N payers, where N is an integer greater than 1. The display module is further configured to, upon receiving a third input from the user regarding a target payer among the N payers, switch from the third interface to a fourth interface. The fourth interface is the payment interface of the payment mini-program corresponding to the target payer. The payment mini-program is an application with payment functionality embedded in the main application. The payment interface includes a payment code provided by the payment mini-program. The owner of the payment mini-program is different from the owner of the main application. Based on the payment order, the main application server sends a query request to the resource payment server corresponding to the payment mini-program. The query request requests the resource payment server to determine whether an authorization relationship has been established between the application account of the main application and the payment account of the payment mini-program. The display module is further configured to, when it is determined that the application account of the main application and the payment account of the payment mini-program have established an authorization relationship, send a first payment instruction to the resource payment server, the first payment instruction being used to instruct the payment mini-program to process the payment order; display a fifth interface, the fifth interface including the payment result after the payment mini-program processes the payment order; if the first communication device number bound to the application account and the second communication device number bound to the payment account match, and the first user identity credential bound to the payment account and the second user identity credential bound to the application account match, then the application account and the payment account have established an authorization relationship.

27. A computing device, the device comprising: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the payment method as described in any one of claims 1-10, the payment method as described in any one of claims 11-20, the payment method as described in claim 21, or the payment method as described in claim 22.

28. A storage medium storing computer program instructions, which, when executed by a processor, implement the payment method as described in any one of claims 1-10, the payment method as described in any one of claims 11-20, the payment method as described in claim 21, or the payment method as described in claim 22.

Images