Payment processing method and apparatus

Abstract

This specification provides a payment processing method and apparatus. One payment processing method includes: obtaining a trigger operation for accessing a second subroutine configured for a first subroutine running on a client; responding to the trigger operation, jumping from the first subroutine to the second subroutine and passing institutional payment parameters to the client's data container; obtaining a payment request for an order to be paid created in the second subroutine and sending it to a server; receiving a payment channel list containing institutional payment channels issued by a payment platform and submitting a payment instruction to the payment platform to process the payment for the order to be paid.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a payment processing method and apparatus. Background Technology

[0002] With the development of internet technology and the popularization of mobile terminals, more and more services are extending to online scenarios. This has led to the emergence of application platform software that can carry multiple sub-programs. This avoids users installing different types of applications on their mobile terminals. Instead, they can use the application sub-programs built into the application platform software to handle services. At the same time, the sub-programs can also make full use of the application platform software's abundant user traffic, thereby helping to improve the sub-program's services. Summary of the Invention

[0003] This specification provides one or more embodiments of a payment processing method, comprising: obtaining a trigger operation for accessing a second subroutine configured for a first subroutine running on a client; responding to the trigger operation, jumping from the first subroutine to the second subroutine and passing institutional payment parameters to the client's data container; obtaining a payment request for an order to be paid created in the second subroutine and sending it to a server; receiving a list of payment channels containing institutional payment channels issued by a payment platform and submitting a payment instruction to the payment platform to process the payment for the order to be paid.

[0004] This specification provides one or more embodiments of another payment processing method, including: receiving a payment request for an order to be paid from a server via a second subroutine running on a client; detecting whether institutional payment parameters are stored in the client's data container, and if so, reading the institutional payment parameters; if the institutional payment parameters meet the requirements for official payment configuration, generating a payment channel list containing institutional payment channels and returning it to the client; and processing the payment for the order to be paid according to the payment instruction submitted by the client.

[0005] This specification provides one or more embodiments of a payment processing apparatus, comprising: a trigger operation acquisition module configured to acquire a trigger operation for an access entry point of a second subroutine configured for a first subroutine running on a client; a subroutine jump module configured to, in response to the trigger operation, jump from the first subroutine to the second subroutine and pass institutional payment parameters to the client's data container; a payment request sending module configured to acquire a payment request for an order to be paid created in the second subroutine and send it to a server; and a payment channel list receiving module configured to receive a payment channel list containing institutional payment channels issued by a payment platform and submit a payment instruction to the payment platform to process the payment for the order to be paid.

[0006] This specification provides one or more embodiments of another payment processing apparatus, including: a payment request receiving module configured to receive a payment request for an order to be paid from a server of a second subroutine running on a client; an institution payment parameter detection module configured to detect whether institution payment parameters are stored in the client's data container, and if so, to run an institution payment parameter reading module; the institution payment parameter reading module configured to read the institution payment parameters; a payment channel list generation module configured to generate a payment channel list containing institution payment channels and return it to the client if the institution payment parameters meet the requirements for official payment; and a payment processing module configured to process the payment for the order to be paid according to the payment instruction submitted by the client.

[0007] This specification provides one or more embodiments of a payment processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain a trigger operation for accessing a second subroutine configured for a first subroutine running on a client; in response to the trigger operation, jump from the first subroutine to the second subroutine and pass institutional payment parameters to a data container of the client; obtain a payment request for an order to be paid created in the second subroutine and send it to a server; receive a list of payment channels containing institutional payment channels issued by a payment platform and submit a payment instruction to the payment platform to process the payment for the order to be paid.

[0008] This specification provides one or more embodiments of another payment processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: receive a payment request for an order to be paid from a server of a second subroutine running on a client; detect whether institutional payment parameters are stored in the client's data container, and if so, read the institutional payment parameters; if the institutional payment parameters meet the requirements for official payment configuration, generate a list of payment channels containing institutional payment channels and return it to the client; and process the payment for the order to be paid according to the payment instruction submitted by the client.

[0009] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: obtaining a trigger operation for accessing a second subroutine configured for a first subroutine running on a client; responding to the trigger operation, jumping from the first subroutine to the second subroutine and passing institutional payment parameters to the client's data container; obtaining a payment request for an order to be paid created in the second subroutine and sending it to a server; receiving a list of payment channels containing institutional payment channels issued by a payment platform and submitting a payment instruction to the payment platform to process the payment for the order to be paid.

[0010] This specification provides one or more embodiments of another storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: receiving a payment request for an order to be paid from a server sent by a second subroutine running on a client; detecting whether institutional payment parameters are stored in the client's data container, and if so, reading the institutional payment parameters; if the institutional payment parameters meet the requirements for official payment configuration, generating a list of payment channels containing institutional payment channels and returning it to the client; and processing the payment for the order to be paid according to the payment instructions submitted by the client. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating a payment processing method provided in one or more embodiments of this specification;

[0013] Figure 2 A flowchart illustrating a payment processing method for group meal scenarios, provided for one or more embodiments of this specification;

[0014] Figure 3 A flowchart illustrating another payment processing method provided in one or more embodiments of this specification;

[0015] Figure 4 A flowchart illustrating another payment processing method for group meal scenarios provided in one or more embodiments of this specification;

[0016] Figure 5A schematic diagram of a payment processing device provided for one or more embodiments of this specification;

[0017] Figure 6 A schematic diagram of another payment processing device provided in one or more embodiments of this specification;

[0018] Figure 7 This specification provides a schematic diagram of the structure of a payment processing device according to one or more embodiments.

[0019] Figure 8 This is a schematic diagram of another payment processing device provided in one or more embodiments of this specification. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0021] This specification provides an example of a payment processing method:

[0022] The payment processing method provided in this application, when the first subroutine running on the client is configured with an access point for the second subroutine, jumps from the first subroutine to the second subroutine in response to a trigger operation targeting the access point. It then passes institutional payment parameters to the client's data container, enabling the payment platform to read these parameters from the data container. After creating a payment order in the second subroutine, it submits the corresponding payment request and receives a list of payment channels containing the institutional payment channels corresponding to the institutional account, issued by the payment platform during the payment processing. It then submits a payment instruction to the payment platform for payment processing. This method, through parameter passing within the client's data container, enables official payments based on institutional accounts, increasing the payment flexibility in the second subroutine while avoiding impact on the payment chain of the second subroutine and eliminating the need to modify it. This enhances the possibility of implementing official payments based on institutional accounts in different scenarios.

[0023] Step S102: Obtain the trigger operation of the access entry of the second subroutine configured for the first subroutine running on the client.

[0024] In this embodiment, the first subroutine and the second subroutine refer to subroutines running on the client side. A subroutine refers to a program function module or application component mounted on the client or application, or a program function module or application component loaded and installed by the client or application, such as a subroutine within an application. From a service perspective, the subroutine has the ability to independently provide a self-contained service.

[0025] Optionally, the first subroutine includes a subroutine that provides services based on the organization code; for example, a subroutine running within the payment client that specifically provides payment using the organization code. The organization code refers to an identification code or payment code set by an organization for the payment, invoicing, and / or reimbursement of its members. This organization code uniquely identifies the organization, and its form can be a QR code, barcode, voice code, or other identification code. Payment processing based on the organization code for payments initiated by organization members can be called official payment. Specifically, the process of payment processing based on the organization code for payments initiated by organization members is the process of using the organization account of the organization member's parent organization to process payments initiated by the organization member.

[0026] In this embodiment, the triggering operation is submitted by the user, who includes: an institutional member with institutional membership and an accessing user without institutional membership. Only institutional members can use the institutional account of their affiliated institution to process payments initiated by them. Since accessing users do not have institutional membership, they obviously do not have a corresponding institutional account to process payments. Therefore, accessing users can only use their own user account (personal account) to process payments.

[0027] Optionally, the second subroutine includes a merchant subroutine and / or a service subroutine for merchant onboarding. For example, a merchant subroutine providing group meal services or a platform subroutine for a group meal service platform where merchants are onboarded.

[0028] In this embodiment, by configuring the access entry point of the second subroutine in the first subroutine, the user can jump to the second subroutine by triggering the access entry point of the second subroutine during the process of accessing the first subroutine. Furthermore, the service connection or processing connection between the first subroutine and the second subroutine can also be realized, and the service processing of the second subroutine can be realized based on the access data of the user accessing the first subroutine.

[0029] In step S104, in response to the triggering operation, the process jumps from the first subroutine to the second subroutine and passes the institution payment parameters to the data container of the client.

[0030] The data container mentioned in this embodiment refers to the runtime framework or runtime engine configured on the client for loading and running subroutines. When the client is configured with a data container, it can load and run subroutines. Here, the execution process of the first and second subroutines on the client is implemented through this data container.

[0031] The institutional payment parameters refer to the parameter information that enables payment processing of payments initiated by institutional members using institutional accounts. Optionally, the institutional payment parameters include at least one of the following: institutional payment priority identifier, institutional account identifier, and order parameters of the pending payment order created in the second subroutine.

[0032] The purpose of passing the institutional payment parameters to the data container here is to use the data container to transfer the data of the institutional members in the first subroutine to the second subroutine. This allows the institutional members to perform payment processing based on the institutional payment parameters passed in the first subroutine during the process of jumping to the second subroutine to initiate payment. This transfers the payment capability of the institutional code in the first subroutine to the second subroutine, thereby enabling the institutional account to process payments initiated by institutional members in the second subroutine.

[0033] The institutional payment priority identifier refers to an identifier that indicates priority in using an institutional account for payment, or in other words, an identifier that indicates priority in using the institutional payment channel corresponding to the institutional account for payment. The order parameters of the order to be paid include at least one of the following: the merchant identifier corresponding to the order to be paid, the triggering method identifier, and the channel identifier of the second subprogram; the triggering method identifier indicates whether access to the second subprogram is triggered by a jump from the first subprogram or through an access entry configured on the client's page.

[0034] In specific implementation, after obtaining the trigger operation of the access entry of the second subroutine configured for the first subroutine running on the client, in response to the trigger operation, the system jumps from the first subroutine to the second subroutine and writes the institution payment parameters into the data container.

[0035] Step S106: Obtain the payment request for the order to be paid created in the second subroutine and send it to the server.

[0036] After jumping from the first subroutine to the second subroutine, if an institutional member creates the pending payment order in the second subroutine based on their operation or request, the member needs to send a payment request for the pending payment order to the server of the second subroutine. After receiving the payment request for the pending payment order, the server of the second subroutine sends the payment request for the pending payment order to the payment platform.

[0037] In the specific execution process, after receiving the payment request sent by the server of the second subroutine, the payment platform checks whether the client's data container stores the institutional payment parameters. If so, it reads the institutional payment parameters. If the institutional payment parameters meet the official payment configuration, it generates a list of payment channels containing institutional payment channels and returns it to the client.

[0038] It should be noted that if a user or organization member does not create a pending payment order by redirecting to the second subroutine through the first subroutine, the organization's payment parameters will not be written into the client's data container. In other words, the pending payment order will not be paid through the official payment method. This method will not affect the payment process of pending payment orders created by users or organization members when they access the second subroutine through the access entry point configured in the client. At the same time, the second subroutine does not need to modify the payment chain, saving the cost of modifying the payment chain and reducing the access cost of integrating official payment, thereby helping to improve the efficiency of expanding official payment in new scenarios.

[0039] Furthermore, it should be noted that the above-described process of obtaining a payment request for an order to be paid created in the second subroutine and sending it to the server can also be replaced by obtaining a payment request for an order to be paid created in the second subroutine and sending it to the payment platform. In this case, after receiving the sent payment request, the payment platform checks whether the client's data container stores institutional payment parameters. If so, it reads the institutional payment parameters. If the institutional payment parameters meet the official payment configuration, it generates a payment channel list containing institutional payment channels and returns it to the client. This can be combined with other corresponding steps provided in this embodiment to form a new implementation method.

[0040] Step S108: Receive a list of payment channels containing institutional payment channels from the payment platform, and submit a payment instruction to the payment platform to process the payment for the order to be paid.

[0041] The institutional payment channel described in this embodiment refers to a payment channel that processes payments initiated by institutional members based on institutional accounts. The payment channel list refers to a list of multiple payment channels; during a specific payment process, any one or more channels from the payment channel list can be selected for the corresponding payment processing.

[0042] In one optional implementation method provided in this embodiment, the payment channel list is generated in the following manner:

[0043] Read the institution's payment parameters stored in the data container;

[0044] If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated.

[0045] The "official payment configuration" refers to the conditions configured by an organization for its members to make official payments. This configuration includes amount configuration and / or merchant configuration; where amount configuration refers to the payment amount configured by the organization for its members that allows official payments, and merchant configuration refers to the designated merchants configured by the organization for its members that allow official payments.

[0046] Here, the official payment configuration can be an official payment configuration pre-configured individually for each member of the organization to which the order to be paid belongs, or it can be an official payment configuration pre-configured uniformly for all members of the organization to which the order to be paid belongs belongs.

[0047] Optionally, the institutional payment channel is determined based on the account identifier of the institutional account included in the institutional payment parameters.

[0048] Furthermore, based on the institutional payment parameters stored in the data container, and assuming that the institutional payment parameters and the order parameters of the order to be paid meet the official payment configuration, a payment channel list containing the institutional payment channels can be generated. Alternatively, based on the institutional payment parameters stored in the data container, and assuming that the order parameters of the order to be paid meet the official payment configuration, a payment channel list containing the institutional payment channels can also be generated.

[0049] Based on the institutional payment priority identifier included in the institutional payment parameters provided above, payment priorities can also be configured for each payment channel in the payment channel list. In one optional implementation of this embodiment, the payment priority of the institutional payment channels included in the payment channel list is determined in the following way: if the institutional payment parameters contain an institutional payment priority identifier, the institutional payment channel corresponding to the institutional account is determined as the payment channel with the first payment priority.

[0050] This allows the organization's payment channel to be the first priority payment channel when an organization member jumps from the first subroutine to the second subroutine on the client side, eliminating the need for the organization member to manually select a payment channel from the payment channel list. This not only improves payment efficiency but also enhances the compatibility of official payments with different payment scenarios.

[0051] In one optional implementation of this embodiment, the payment processing of the pending payment order includes: making payment for the pending payment order based on the institutional account corresponding to the institutional payment channel, and marking the pending payment order with an official payment tag.

[0052] Furthermore, in actual payment processing, situations may arise where the institutional account has insufficient balance or other circumstances prevent the independent use of the institutional account to process payments initiated by institutional members in the second subroutine. To address this, this embodiment provides a payment logic that combines the institutional account and the user account (the institutional member's personal account) for payment, thereby improving the success rate of official payments. Specifically, in one optional implementation of this embodiment, processing the payment for the pending order includes:

[0053] Payment is made for the pending orders based on the institutional account corresponding to the institutional payment channel and the user account corresponding to the candidate payment channel.

[0054] Wherein, the first payment amount of the institutional account is the amount allocated to the user corresponding to the order to be paid under the institutional account; the second payment amount of the user account is the difference between the total payment amount of the order to be paid and the first payment amount. The candidate payment channel can be the payment channel corresponding to the user account with the second payment priority in the payment channel list, or it can be a payment channel manually selected by institutional members in the payment channel list.

[0055] In practical applications, after an institutional member jumps from the first subroutine to the second subroutine, they can use the institutional account provided by the first subroutine to process payments initiated by the institutional member in the second subroutine. Alternatively, they can jump from the first subroutine to the client's third or fourth subroutine, and use the institutional account provided by the first subroutine to process payments initiated by the institutional member in the third or fourth subroutine. It should be noted that the process of using the institutional account provided by the first subroutine to process payments initiated by the institutional member in the third or fourth subroutine is similar to the process described above, and can be implemented as described above. This embodiment will not elaborate further.

[0056] Therefore, in order to avoid the institutional payment parameters written into the client's data container from affecting the client's subsequent payment process, in an optional implementation of this embodiment, after submitting a payment instruction to the payment platform to process the payment of the order to be paid, if the exit instruction of the second subroutine is detected, the institutional payment parameters stored in the data container are deleted.

[0057] The above-described payment processing method can be executed by the client. The following method embodiment provides another payment processing method that can be executed by the payment platform. The two cooperate with each other during execution. Therefore, the above implementation process can be read with reference to the corresponding content of the following method embodiment, and similarly, the following implementation process can also be read with reference to the corresponding content of the above method embodiment.

[0058] The following example uses a payment processing method provided in this embodiment in a group meal scenario as an example, combined with... Figure 2 The payment processing method provided in this embodiment will be further explained below. Figure 2 The payment processing method applied to group meal scenarios includes the following steps.

[0059] Step S202: Obtain the trigger operation of the access entry of the group meal subroutine configured for the organization code subroutine running on the client.

[0060] In step S204, in response to the trigger operation, the system jumps from the organization code subroutine to the group meal subroutine and passes the organization payment parameters to the client's data container.

[0061] Step S206: Obtain the payment request for the group meal order created in the group meal subroutine and send it to the server.

[0062] Step S208: Receive a list of payment channels containing institutional payment channels from the payment platform, and submit a payment instruction to the payment platform to process the group meal order payment.

[0063] Step S210: If an exit instruction from the group meal subroutine is detected, delete the institution payment parameters stored in the data container.

[0064] In this embodiment, steps S202 to S210 are executed by the client. It should be noted that the client's execution of steps S202 to S210 is coordinated with the payment platform's execution of steps S402 to S412 in the following embodiment. Therefore, when reading this embodiment, please refer to the corresponding content of steps S402 to S412 below. Correspondingly, when reading steps S402 to S412 below, please also refer to the corresponding content of steps S202 to S210 provided in this embodiment.

[0065] Another payment processing method embodiment provided in this specification:

[0066] Step S302: Receive a payment request for an order to be paid from the server of the second subroutine running on the client.

[0067] In this embodiment, the payment request for the order to be paid is generated after the client jumps from the first subroutine to the second subroutine in response to a trigger operation. The trigger operation is submitted to the access entry of the second subroutine configured in the first subroutine.

[0068] In this embodiment, the first subroutine and the second subroutine refer to subroutines running on the client side. A subroutine refers to a program function module or application component mounted on the client or application, or a program function module or application component loaded and installed by the client or application, such as a subroutine within an application. From a service perspective, the subroutine has the ability to independently provide a self-contained service.

[0069] Optionally, the first subroutine includes a subroutine that provides services based on the organization code; for example, a subroutine running within the payment client that specifically provides payment using the organization code. The organization code refers to an identification code or payment code set by an organization for the payment, invoicing, and / or reimbursement of its members. This organization code uniquely identifies the organization, and its form can be a QR code, barcode, voice code, or other identification code. Payment processing based on the organization code for payments initiated by organization members can be called official payment. Specifically, the process of payment processing based on the organization code for payments initiated by organization members is the process of using the organization account of the organization member's parent organization to process payments initiated by the organization member.

[0070] In this embodiment, the triggering operation is submitted by the user, who includes: an institutional member with institutional membership and an accessing user without institutional membership. Only institutional members can use the institutional account of their affiliated institution to process payments initiated by them. Since accessing users do not have institutional membership, they obviously do not have a corresponding institutional account to process payments. Therefore, accessing users can only use their own user account (personal account) to process payments.

[0071] Optionally, the second subroutine includes a merchant subroutine and / or a service subroutine for merchant onboarding. For example, a merchant subroutine providing group meal services or a platform subroutine for a group meal service platform where merchants are onboarded.

[0072] In this embodiment, by configuring the access entry point of the second subroutine in the first subroutine, the user can jump to the second subroutine by triggering the access entry point of the second subroutine during the process of accessing the first subroutine. Furthermore, the service connection or processing connection between the first subroutine and the second subroutine can also be realized, and the service processing of the second subroutine can be realized based on the access data of the user accessing the first subroutine.

[0073] After jumping from the first subroutine to the second subroutine, if an institutional member creates the pending payment order in the second subroutine based on their operation or request, they need to send a payment request for the pending payment order to the server of the second subroutine. After receiving the payment request for the pending payment order, the server of the second subroutine sends the payment request for the pending payment order to the payment platform. Here, the server of the second subroutine receives the payment request for the pending payment order sent by the server of the second subroutine.

[0074] Furthermore, the above-described implementation process of receiving the payment request of the pending order sent by the server of the second subroutine can also be replaced by an implementation process of receiving the payment request of the pending order sent by the client. In this case, the client sends the payment request of the pending order in response to the call of the second subroutine, and can form a new implementation method with other corresponding steps provided in this embodiment.

[0075] Step S304: Detect whether the client's data container stores institutional payment parameters.

[0076] The institutional payment parameters refer to the parameter information that enables payment processing of payments initiated by institutional members using institutional accounts. Optionally, the institutional payment parameters include at least one of the following: institutional payment priority identifier, institutional account identifier, and order parameters of the pending payment order created in the second subroutine.

[0077] The purpose of passing the institutional payment parameters to the data container here is to use the data container to transfer the data of the institutional members in the first subroutine to the second subroutine. This allows the institutional members to perform payment processing based on the institutional payment parameters passed in the first subroutine during the process of jumping to the second subroutine to initiate payment. This transfers the payment capability of the institutional code in the first subroutine to the second subroutine, thereby enabling the institutional account to process payments initiated by institutional members in the second subroutine.

[0078] The institutional payment priority identifier refers to an identifier that indicates priority in using an institutional account for payment, or in other words, an identifier that indicates priority in using the institutional payment channel corresponding to the institutional account for payment. The order parameters of the order to be paid include at least one of the following: the merchant identifier corresponding to the order to be paid, the triggering method identifier, and the channel identifier of the second subprogram; the triggering method identifier indicates whether access to the second subprogram is triggered by a jump from the first subprogram or through an access entry configured on the client's page.

[0079] After receiving the payment request for the order to be paid from the server of the second subroutine, in response to the payment request, the system checks whether the data container of the client stores the organization payment parameters; if the organization payment parameters are stored, it indicates that the order to be paid is an order to be paid created in the second subroutine after the organization member jumps from the first subroutine to the second subroutine, and then the organization payment parameters stored in the data container of the client are read.

[0080] If the institution's payment parameters are not stored, it indicates that the order to be paid is not an order created in the second subroutine after the institution member jumps from the first subroutine to the second subroutine. It may be an order created in the second subroutine during the process of accessing the second subroutine through the access entry configured by the client. In this regard, in an optional implementation of this embodiment, a list of payment channels containing the payment channels corresponding to the user accounts of the institution members is generated and returned to the client, or the payment processing of the order to be paid is performed based on the user account of the accessing user corresponding to the order to be paid.

[0081] Optionally, the institutional payment parameters are passed to the data container after a trigger operation jumps from the first subroutine running on the client to the second subroutine; the trigger operation is submitted to the access entry of the second subroutine configured for the first subroutine.

[0082] Step S306: Read the payment parameters of the institution.

[0083] Step S308: If the institution's payment parameters meet the requirements for official payment configuration, generate a list of payment channels containing the institution's payment channels and return it to the client.

[0084] The official payment configuration described in this embodiment refers to the conditions configured by an organization for its members to make official payments. The official payment configuration includes amount configuration and / or merchant configuration; wherein, amount configuration refers to the payment amount configured by the organization for its members that can be made using official payments, and merchant configuration refers to the designated merchants configured by the organization for its members that can use official payments. The organization's payment parameters satisfy the payment channel configuration, including that the merchant identifier carried by the organization's payment parameters matches the merchant configuration for official payments.

[0085] Here, the official payment configuration can be an official payment configuration pre-configured individually for each member of the organization to which the order to be paid belongs, or it can be an official payment configuration pre-configured uniformly for all members of the organization to which the order to be paid belongs belongs.

[0086] The institutional payment channel refers to a payment channel that processes payments initiated by institutional members based on institutional accounts. The payment channel list is a list of multiple payment channels; during a specific payment process, any one or more channels from the payment channel list can be selected for corresponding payment processing. Optionally, the institutional payment channel is determined based on the account identifier of the institutional account included in the institutional payment parameters.

[0087] Based on the institutional payment priority identifier included in the institutional payment parameters provided above, payment priorities can also be configured for each payment channel in the payment channel list. In one optional implementation of this embodiment, the payment priority of the institutional payment channels included in the payment channel list is determined in the following way: if the institutional payment parameters contain an institutional payment priority identifier, the institutional payment channel corresponding to the institutional account is determined as the payment channel with the first payment priority.

[0088] This allows the organization's payment channel to be the first priority payment channel when an organization member jumps from the first subroutine to the second subroutine on the client side, eliminating the need for the organization member to manually select a payment channel from the payment channel list. This not only improves payment efficiency but also enhances the compatibility of official payments with different payment scenarios.

[0089] In addition, if the payment parameters of the organization do not meet the requirements for official payment, a list of payment channels containing the payment channels corresponding to the user accounts of the organization members is generated and returned to the client; or, based on the user account of the accessing user corresponding to the order to be paid, the payment processing of the order to be paid is performed.

[0090] It should be noted that the above-mentioned method of generating a payment channel list containing institutional payment channels and returning it to the client if the institutional payment parameters meet the official payment configuration can be replaced by: generating a payment channel list containing institutional payment channels and returning it to the client if the institutional payment parameters and the order parameters of the order to be paid meet the official payment configuration; or, generating a payment channel list containing institutional payment channels and returning it to the client if the order parameters of the order to be paid meet the official payment configuration, and combining this method with other corresponding steps provided in this embodiment to form a new implementation.

[0091] Step S310: Process the payment for the order to be paid according to the payment instruction submitted by the client.

[0092] In one optional implementation of this embodiment, the payment processing of the pending order is carried out according to the payment instruction submitted by the client, including: making payment on the pending order based on the institutional account corresponding to the institutional payment channel, and marking the pending order with an official payment tag.

[0093] Furthermore, in actual payment processing, situations may arise where the institutional account has insufficient balance or other circumstances prevent the independent use of the institutional account to process payments initiated by institutional members in the second subroutine. To address this, this embodiment also provides a payment logic that combines the institutional account and the user account (the institutional member's own personal account) for payment, thereby improving the success rate of official payments. Specifically, in one optional implementation of this embodiment, the payment processing of the pending order is performed according to the payment instruction submitted by the client, including:

[0094] Payment is made for the pending orders based on the institutional account corresponding to the institutional payment channel and the user account corresponding to the candidate payment channel.

[0095] Wherein, the first payment amount of the institutional account is the amount allocated to the user corresponding to the order to be paid under the institutional account; the second payment amount of the user account is the difference between the total payment amount of the order to be paid and the first payment amount. The candidate payment channel can be the payment channel corresponding to the user account with the second payment priority in the payment channel list, or it can be a payment channel manually selected by institutional members in the payment channel list.

[0096] The following example uses a payment processing method provided in this embodiment in a group meal scenario as an example, combined with... Figure 4 The payment processing method provided in this embodiment will be further explained below. Figure 4 The payment processing method applied to group meal scenarios includes the following steps.

[0097] Step S402: Receive the payment request for the group meal order sent by the server of the group meal subroutine running on the client.

[0098] Step S404: Detect whether the client's data container stores institutional payment parameters;

[0099] If so, proceed to step S406;

[0100] If not, proceed to step S412.

[0101] Step S406: Read the institutional payment parameters stored in the data container.

[0102] Step S408: If the institution's payment parameters meet the requirements for official payment configuration, generate a list of payment channels containing the institution's payment channels and return it to the client.

[0103] Step S410: Based on the payment instruction submitted by the client, make payment for the group meal order based on the institutional account corresponding to the institutional payment channel, and mark the group meal order with an official payment label.

[0104] Step S412: Process the payment for the group meal order based on the user account of the accessing user corresponding to the group meal order.

[0105] This specification provides an embodiment of a payment processing device as follows:

[0106] In the above embodiments, a payment processing method is provided, and correspondingly, a payment processing device is also provided, which will be described below with reference to the accompanying drawings.

[0107] Reference Figure 5 The diagram shows a payment processing device provided in this embodiment.

[0108] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0109] This embodiment provides a payment processing device, including:

[0110] The trigger operation acquisition module 502 is configured to acquire the trigger operation of the access entry of the second subroutine configured for the first subroutine running on the client.

[0111] The subroutine jump module 504 is configured to jump from the first subroutine to the second subroutine in response to the triggering operation, and pass the institution payment parameters to the data container of the client;

[0112] The payment request sending module 506 is configured to obtain a payment request for an order to be paid created in the second subroutine and send it to the server;

[0113] The payment channel list receiving module 508 is configured to receive a payment channel list containing institutional payment channels issued by the payment platform, and submit a payment instruction to the payment platform to process the payment of the order to be paid.

[0114] Another embodiment of the payment processing device provided in this specification is as follows:

[0115] In the above embodiments, another payment processing method is provided, and correspondingly, another payment processing device is also provided, which will be described below with reference to the accompanying drawings.

[0116] Reference Figure 6 The diagram shows a payment processing device provided in this embodiment.

[0117] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0118] This embodiment provides a payment processing device, including:

[0119] The payment request receiving module 602 is configured to receive payment requests for pending orders sent by the server of a second subroutine running on the client.

[0120] The institutional payment parameter detection module 604 is configured to detect whether institutional payment parameters are stored in the data container of the client. If so, the institutional payment parameter reading module 606 is run.

[0121] The institution payment parameter reading module 606 is configured to read the institution payment parameters;

[0122] The payment channel list generation module 608 is configured to generate a payment channel list containing the institution's payment channels and return it to the client if the institution's payment parameters meet the requirements for official payment.

[0123] The payment processing module 610 is configured to process the payment of the order to be paid based on the payment instruction submitted by the client.

[0124] This specification provides the following embodiment of a payment processing device:

[0125] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a payment processing device for executing the payment processing method provided above. Figure 7 This is a schematic diagram of the structure of a payment processing device provided for one or more embodiments of this specification.

[0126] This embodiment provides a payment processing device, including:

[0127] like Figure 7As shown, payment processing devices can vary significantly due to differences in configuration or performance. They may include one or more processors 701 and memory 702, with memory 702 storing one or more application programs or data. Memory 702 can be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module including a series of computer-executable instructions within the payment processing device. Furthermore, processor 701 may be configured to communicate with memory 702, executing the series of computer-executable instructions stored in memory 702 on the payment processing device. The payment processing device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, one or more keyboards 706, etc.

[0128] In one specific embodiment, the payment processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0129] Get the trigger operation for the access entry of the second subroutine configured for the first subroutine running on the client;

[0130] In response to the triggering operation, the system jumps from the first subroutine to the second subroutine and passes the institution payment parameters to the client's data container;

[0131] Obtain the payment request for the order to be paid created in the second subroutine and send it to the server;

[0132] Receive a list of payment channels, including institutional payment channels, from the payment platform, and submit a payment instruction to the payment platform to process the payment for the order to be paid.

[0133] Another embodiment of the payment processing device provided in this specification is as follows:

[0134] Corresponding to the other payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide another payment processing device for executing the payment processing method provided above. Figure 8 This is a schematic diagram of another payment processing device provided in one or more embodiments of this specification.

[0135] This embodiment provides a payment processing device, including:

[0136] like Figure 8 As shown, payment processing devices can vary significantly due to differences in configuration or performance. They may include one or more processors 801 and memories 802, with the memory 802 storing one or more application programs or data. The memory 802 can be temporary or persistent storage. The application programs stored in the memory 802 may include one or more modules (not shown), each module including a series of computer-executable instructions within the payment processing device. Furthermore, the processor 801 may be configured to communicate with the memory 802, executing the series of computer-executable instructions stored in the memory 802 on the payment processing device. The payment processing device may also include one or more power supplies 803, one or more wired or wireless network interfaces 804, one or more input / output interfaces 805, one or more keyboards 806, etc.

[0137] In one specific embodiment, the payment processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0138] Receive payment requests for pending orders sent by the server from the second subroutine running on the client;

[0139] Detect whether the client's data container stores institutional payment parameters; if so, read the institutional payment parameters.

[0140] If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated and returned to the client;

[0141] The payment process for the pending order is performed based on the payment instruction submitted by the client.

[0142] This specification provides an example of a storage medium as follows:

[0143] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium.

[0144] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0145] Get the trigger operation for the access entry of the second subroutine configured for the first subroutine running on the client;

[0146] In response to the triggering operation, the system jumps from the first subroutine to the second subroutine and passes the institution payment parameters to the client's data container;

[0147] Obtain the payment request for the order to be paid created in the second subroutine and send it to the server;

[0148] Receive a list of payment channels, including institutional payment channels, from the payment platform, and submit a payment instruction to the payment platform to process the payment for the order to be paid.

[0149] It should be noted that the embodiments of a storage medium and the embodiments of a payment processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0150] Another embodiment of the storage medium provided in this specification is as follows:

[0151] In response to the other payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide another storage medium.

[0152] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0153] Receive payment requests for pending orders sent by the server from the second subroutine running on the client;

[0154] Detect whether the client's data container stores institutional payment parameters; if so, read the institutional payment parameters.

[0155] If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated and returned to the client;

[0156] The payment process for the pending order is performed based on the payment instruction submitted by the client.

[0157] It should be noted that the embodiments of another storage medium in this specification and the embodiments of another payment processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0158] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0159] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0160] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0161] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0162] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0163] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0164] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0165] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0166] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0167] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0168] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0169] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0170] It should also be noted that 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 limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0171] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0172] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0173] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A payment processing method, comprising: Get the trigger operation for the access entry point of the merchant subprogram configured for the organization code subprogram running on the client; In response to the triggering operation, the system jumps from the institution code subroutine to the merchant subroutine and passes the institution payment parameters to the data container of the client. The system retrieves a payment request for an order to be paid created in the merchant subroutine and sends it to the payment platform to read the institution's payment parameters. If the institution's payment parameters meet the official payment configuration, a payment channel list containing the institution's payment channels is generated. The payment request is generated after the system jumps from the institution code subroutine to the merchant subroutine in response to the triggering operation. The official payment configuration includes the payment amount and designated merchant that the institution configures for its members to use official payments. The system receives the list of payment channels containing institutional payment channels from the payment platform, makes payments on the pending orders based on the institutional accounts corresponding to the institutional payment channels, and marks the pending orders with an official payment tag.

2. The payment processing method according to claim 1, wherein each payment channel in the payment channel list is configured with its own payment priority; in, The payment priority of the institution's payment channels is determined in the following manner: If the institutional payment parameters contain an institutional payment priority identifier, then the institutional payment channel corresponding to the institutional account will be determined as the payment channel with the first payment priority.

3. The payment processing method according to claim 1, wherein the institutional payment parameters include at least one of the following: institutional payment priority identifier, institutional account identifier, and order parameters of the pending payment order created in the merchant subroutine.

4. The payment processing method according to claim 1, after the steps of receiving the payment channel list containing institutional payment channels issued by the payment platform, making payment for the order to be paid based on the institutional account corresponding to the institutional payment channel, and marking the order to be paid with an official payment tag, further includes: If an exit command is detected from the merchant subroutine, the institution's payment parameters stored in the data container are deleted.

5. A payment processing method, comprising: Receive payment requests for pending orders sent by the server from the merchant subroutine running on the client. The payment request is generated in response to a triggering operation that redirects the payment request from the institution code subroutine to the merchant subroutine. Detect whether the client's data container stores institutional payment parameters; if so, read the institutional payment parameters. If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated and returned to the client; the official payment configuration includes the payment amount and designated merchants that the institution configures for its members to use official payments. The payment for the pending orders is made based on the institutional account corresponding to the institutional payment channel, and the pending orders are marked with an official payment tag.

6. The payment processing method according to claim 5, wherein the institution payment parameters are passed into the data container after the institution code subroutine running on the client jumps to the merchant subroutine in response to the triggering operation; The triggering operation is a submission of the access entry of the merchant subprogram configured in the organization code subprogram.

7. The payment processing method according to claim 5, wherein each payment channel in the payment channel list is configured with its own payment priority; in, The payment priority of the institution's payment channels is determined in the following manner: If the institutional payment parameters contain an institutional payment priority identifier, then the institutional payment channel corresponding to the institutional account will be determined as the payment channel with the first payment priority.

8. The payment processing method according to claim 5, if the result of the operation to detect whether the data container of the client stores institutional payment parameters is no, the following operation is performed: The payment process for the pending payment order is performed based on the user account of the accessing user corresponding to the pending payment order.

9. A payment processing device, comprising: The trigger operation acquisition module is configured to acquire the trigger operation of the access entry point of the merchant subprogram configured for the organization code subprogram running on the client. The subroutine jump module is configured to jump from the institution code subroutine to the merchant subroutine in response to the trigger operation, and pass the institution payment parameters to the data container of the client; The payment request sending module is configured to acquire a payment request for an order to be paid created in the merchant subroutine and send it to the payment platform to read the institution's payment parameters. If the institution's payment parameters meet the official payment configuration, the module generates a payment channel list containing the institution's payment channels. The payment request is generated after the system jumps from the institution code subroutine to the merchant subroutine in response to the triggering operation. The official payment configuration includes the payment amount and designated merchant that the institution has configured for its members to use official payments. The payment channel list receiving module is configured to receive the payment channel list containing institutional payment channels issued by the payment platform, make payments for the pending payment orders based on the institutional accounts corresponding to the institutional payment channels, and mark the pending payment orders with an official payment tag.

10. A payment processing device, comprising: The payment request receiving module is configured to receive payment requests for pending orders sent by the server of the merchant subroutine running on the client. The payment request is generated in response to a triggering operation that redirects the payment request from the institution code subroutine to the merchant subroutine. The institutional payment parameter detection module is configured to detect whether institutional payment parameters are stored in the client's data container; if so, the institutional payment parameter reading module is run. The institutional payment parameter reading module is configured to read the institutional payment parameters; The payment channel list generation module is configured to generate a payment channel list containing the institution's payment channels and return it to the client if the institution's payment parameters meet the official payment configuration; the official payment configuration includes the payment amount and designated merchants that the institution configures for its members to use official payments. The payment processing module is configured to make payments for the pending orders based on the institutional account corresponding to the institutional payment channel, and to mark the pending orders with an official payment tag.

11. A payment processing device, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Get the trigger operation for the access entry point of the merchant subprogram configured for the organization code subprogram running on the client; In response to the triggering operation, the system jumps from the institution code subroutine to the merchant subroutine and passes the institution payment parameters to the data container of the client. The system retrieves a payment request for an order to be paid created in the merchant subroutine and sends it to the payment platform to read the institution's payment parameters. If the institution's payment parameters meet the official payment configuration, a payment channel list containing the institution's payment channels is generated. The payment request is generated after the system jumps from the institution code subroutine to the merchant subroutine in response to the triggering operation. The official payment configuration includes the payment amount and designated merchant that the institution configures for its members to use official payments. The system receives the list of payment channels containing institutional payment channels from the payment platform, makes payments on the pending orders based on the institutional accounts corresponding to the institutional payment channels, and marks the pending orders with an official payment tag.

12. A payment processing device, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: The server receives payment requests for pending orders from the merchant subroutine running on the client; the payment request is generated after a trigger operation redirects the user from the organization code subroutine to the merchant subroutine. Detect whether the client's data container stores institutional payment parameters; if so, read the institutional payment parameters. If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated and returned to the client; the official payment configuration includes the payment amount and designated merchants that the institution configures for its members to use official payments. The payment for the pending orders is made based on the institutional account corresponding to the institutional payment channel, and the pending orders are marked with an official payment tag.

13. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Get the trigger operation for the access entry point of the merchant subprogram configured for the organization code subprogram running on the client; In response to the triggering operation, the system jumps from the institution code subroutine to the merchant subroutine and passes the institution payment parameters to the data container of the client. The system retrieves a payment request for an order to be paid created in the merchant subroutine and sends it to the payment platform to read the institution's payment parameters. If the institution's payment parameters meet the official payment configuration, a payment channel list containing the institution's payment channels is generated. The payment request is generated after the system jumps from the institution code subroutine to the merchant subroutine in response to the triggering operation. The official payment configuration includes the payment amount and designated merchant that the institution configures for its members to use official payments. The system receives the list of payment channels containing institutional payment channels from the payment platform, makes payments on the pending orders based on the institutional accounts corresponding to the institutional payment channels, and marks the pending orders with an official payment tag.

14. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: The server receives payment requests for pending orders from the merchant subroutine running on the client; the payment request is generated after a trigger operation redirects the user from the organization code subroutine to the merchant subroutine. Detect whether the client's data container stores institutional payment parameters; if so, read the institutional payment parameters. If the institution's payment parameters meet the requirements for official payment configuration, a list of payment channels containing the institution's payment channels is generated and returned to the client; the official payment configuration includes the payment amount and designated merchants that the institution configures for its members to use official payments. The payment for the pending orders is made based on the institutional account corresponding to the institutional payment channel, and the pending orders are marked with an official payment tag.

Images