CN113205331B

CN113205331B - Payment method and device, electronic equipment and storage medium

Info

Publication number: CN113205331B
Application number: CN202110692257.8A
Authority: CN
Inventors: 施萍; 吕伟强; 胡容海; 祁鑫; 刘朗君; 朱长云; 贾泽龙; 陆健
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-11-24
Filing date: 2020-11-24
Publication date: 2023-04-07
Anticipated expiration: 2040-11-24
Also published as: CN112132565B; CN112132565A; CN113205331A

Abstract

The application provides a payment method and device, electronic equipment and a storage medium. Wherein the method comprises receiving a payment request; the payment request comprises an account identifier of an employee account needing payment operation; the employee account binds to the enterprise account used to make the payment deduction. And responding to the payment request, and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account. And if the payment request meets the payment withholding condition, completing the payment operation corresponding to the payment request from the enterprise account.

Description

Payment method and device, electronic equipment and storage medium

Technical Field

The present application relates to computer technologies, and in particular, to a payment method and apparatus, an electronic device, and a storage medium.

Background

In the due public payment scene, enterprise prepayment and employee charging are mainly included. The enterprise advance payment means that the enterprise advance payment of a certain amount of funds of the employees for public matters such as employee business trip, business banquet, purchase and the like. The pre-paid bill can be charged by the invoice after the employee consumes the invoice. The employee support mainly means that the employee pays by using own fund and applies for reimbursement to the enterprise according to the ticket. The enterprise pays to the staff after being approved.

Therefore, whether enterprise prepayment or employee underpinning, the public payment process is complicated, and the burden of the employee and the financial staff of the enterprise is increased.

Disclosure of Invention

In view of the above, the present application discloses at least a payment method applied to a server; the method comprises the following steps:

receiving a payment request; the payment request comprises an account identifier of an employee account needing payment operation; the employee account is bound with an enterprise account for payment deduction;

responding to the payment request, and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; if the payment request satisfies the payment withholding condition,

and completing the payment operation corresponding to the payment request from the enterprise account.

In some embodiments, the method for binding the enterprise account with the employee account includes:

receiving a binding request initiated by an enterprise user corresponding to the enterprise account through an enterprise client; the binding request comprises the employee account, an enterprise account bound with the employee account and a payment withholding condition set for an employee corresponding to the employee account by an enterprise user corresponding to the enterprise account;

responding to the binding request, initiating a binding confirmation request to the employee client, binding the enterprise account and the employee account after receiving a confirmation response which is sent by the employee client and aims at the binding confirmation request, and storing the corresponding relation among the employee account, the enterprise account and the payment withholding condition.

The application also provides a payment method which is applied to the employee client; the method comprises the following steps:

responding to a payment operation performed by an employee through an employee account, initiating a payment request to a server, so that the server responds to the payment request, performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request, and completing the payment operation corresponding to the payment request from the enterprise account when the payment request meets the payment withholding condition; the enterprise account comprises an enterprise account which is bound with the employee account and used for payment deduction.

The application also provides a payment device which is applied to the server side; the above-mentioned device includes:

the receiving module receives a payment request; the payment request comprises an account identifier of an employee account needing payment operation; the employee account is bound with an enterprise account for payment deduction;

the verification and payment module is used for responding to the payment request and performing payment verification on the payment request so as to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; if the payment request satisfies the payment withholding condition,

In some illustrative embodiments, the apparatus further comprises:

the binding module receives a binding request initiated by the enterprise account through an enterprise client; wherein, part of the information of the binding request is used for indicating the employee account and the payment withholding condition;

responding to the binding request, initiating a binding confirmation request to the employee client, and storing the payment withholding condition, the corresponding relation between the enterprise account and the employee account, and the corresponding relation between the payment withholding condition and the employee account after receiving a confirmation response which is sent by the employee client and aims at the binding confirmation request.

The application also provides a payment device which is applied to the staff client; the above-mentioned device includes:

the system comprises a sending module, a payment verification module and a payment verification module, wherein the sending module is used for responding to a payment operation performed by an employee through an employee account and initiating a payment request to a server so as to enable the server to respond to the payment request and perform payment verification on the payment request so as to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request or not, and when the payment request meets the payment withholding condition, completing the payment operation corresponding to the payment request from the enterprise account; the enterprise account comprises an enterprise account which is bound with the employee account and used for payment deduction.

The present application further provides an electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to invoke executable instructions stored in the memory to implement:

receiving a payment request; the payment request comprises an account identifier of an employee account needing to be subjected to payment operation; the employee account is bound with an enterprise account for payment deduction;

responding to the payment request, and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; and if the payment request meets the payment withholding condition, completing the payment operation corresponding to the payment request from the enterprise account.

The present application further provides an electronic device, comprising:

a processor;

a memory for storing the processor-executable instructions;

The present application also provides a computer-readable storage medium, in which a computer program is stored, the computer program being configured to perform:

The present application also provides a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute:

In the technical scheme, on one hand, whether a payment request initiated by an employee account meets a set payment withholding condition is determined in the server, and an enterprise replaces an employee to pay when the request meets the payment withholding condition, so that a fund trust mechanism is established between the enterprise and the employee, the enterprise bound by the employee replaces the employee to complete payment after the employee initiates the payment request, the procedure of paying by public payment is simplified, the burden of the employee and financial staff of the enterprise is reduced, and the efficiency of paying by public payment is improved.

On the other hand, the payment method applied to the employee client is provided in the employee client, so that after the employee conducts a consumption action, enterprise payment can be achieved through interaction with the employee client, the procedure of payment due to public payment is simplified, and the payment efficiency is improved.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

In order to more clearly illustrate one or more embodiments of the present application or technical solutions in the related art, the drawings needed to be used in the description of the embodiments or the related art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in one or more embodiments of the present application, and other drawings can be obtained by those skilled in the art without inventive exercise.

FIG. 1 is a method flow diagram of a payment method illustrated herein;

FIG. 2 is a flow chart illustrating a method of binding according to the present application;

FIG. 3 is a schematic view of a payment scenario illustrated herein;

FIG. 4 is a flow chart illustrating a binding method according to the present application;

FIG. 5 is a schematic illustration of a payment process shown in the present application;

FIG. 6 is a schematic view of a payment device according to the present application;

fig. 7 is a schematic diagram of a hardware structure of an electronic device shown in the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should also be understood that the word "if" as used herein may be interpreted as "at 8230; \8230when" or "when 8230; \823030, when" or "in response to a determination", depending on the context.

In a first aspect of the present application, a payment method is presented. The method can be applied to the server side. The server may be a local server, a remote server, or a cloud server providing services for the corresponding client. The server side can be formed on the basis of a plurality of servers or cloud servers. The specific type of server or cloud server is not limited herein.

For example, in an equity payment scenario, the clients may include an employee client, a payee client, and an enterprise client. The server can be a background server which provides services such as payment, enterprise and employee binding data storage and the like for the clients.

The employee client, payee client and enterprise client may be clients with payment collection functions. When the client logs in different object accounts, the client becomes a client aiming at different crowds.

The method comprises the steps of verifying a payment request initiated by an employee account needing payment operation according to a payment withholding condition set by an enterprise for the employee, and completing the payment operation corresponding to the payment request from the enterprise account after the verification is passed.

Therefore, the method establishes a fund trust mechanism between the enterprise and the employee by determining whether the payment request initiated by the employee account meets the set payment withholding condition and replacing the employee with the enterprise for payment when the request meets the payment withholding condition, so that the enterprise bound by the employee replaces the payment after the employee initiates the payment request, thereby simplifying the procedure of the due payment, reducing the burden of the employee and financial staff of the enterprise and improving the efficiency of the due payment.

For example, in a pre-reimbursement scenario, the enterprise may need to first prepare a fund for the employee in advance to pay the employee an amount of money. The bill can be charged by the invoice after the employee consumes.

However, in practical situations, how the employee uses after getting the funds is difficult for the enterprise to control. Therefore, it is necessary for the enterprise supervisor (e.g., financial staff) to control the consumption of the staff with great expenditure.

Compared with the enterprise prepayment scene, the method and the system have the advantages that whether the payment request initiated by the employee account meets the set payment withholding condition or not is determined, and the enterprise replaces the employee to pay when the request meets the payment withholding condition, so that the enterprise can set the payment withholding condition to control the employee consumption, a fund trust mechanism is established between the enterprise and the employee, the enterprise bound by the employee replaces the payment after the employee initiates the payment request, the due public payment process is simplified, the burden of the employee and the financial staff of the enterprise is reduced, and the due public payment efficiency is improved.

Referring to fig. 1, fig. 1 is a flowchart illustrating a payment method according to the present application.

As shown in fig. 1, the payment method may include:

s102, receiving a payment request; the payment request comprises an account identifier of an employee account needing payment operation; the employee account binds to the enterprise account used to make the payment deduction.

The employee account is specifically an account corresponding to the employee one to one. In some examples, the employee may apply for an account with one-to-one correspondence to the employee via the client. After applying for the account, the employee can make payment operation through the account of the employee corresponding to the employee.

The enterprise accounts are specifically accounts corresponding to the enterprises one by one. In some examples, an enterprise may apply for an account with itself in a one-to-one correspondence via a client. After applying for the account, the enterprise can initiate operations such as binding with employees and setting payment withholding conditions through the enterprise account. The business may also complete an official payment through the business account in place of an employee bound to the business. The account type of the enterprise account may be a bank account (a debit account or a credit account), an account opened by a third party payment company, or an overdraft account, which is not limited in this application.

The payment request is specifically a payment demand generated by public consumption of staff. In some examples, the payment request includes a payment request initiated by the employee client or a payment request initiated by a payee client corresponding to the payee account. In some examples, the payment request typically includes information about the time of the payment, the payment flow (i.e., the payer account and the payee account), and the amount of funds transferred.

For example, when the employee needs to stay at a hotel due to a business trip, the employee can scan the cash register provided by the target hotel through the code scanning function of the employee client. After the code scanning is finished, a consumption order between the employee and the target hotel is formed in the employee client. After the consumption order is formed, the staff client can initiate a payment request to the server based on the consumption order to complete subsequent payment. The scanning function may be provided by an applet in the employee client or a function carried by the employee client, which is not limited in this application.

For another example, when the employee needs to stay in the hotel due to a business trip, the employee may provide a payment code through the employee client, and the code scanning operation is performed by the payee client of the target hotel. And after the code scanning operation is completed, a consumption order between the employee and the target hotel is formed on the payee client. After the consumption order is formed, the payee client may initiate a payment receipt request to the server based on the consumption order to complete a subsequent payment.

After receiving the payment request, S104 may be continuously performed, and in response to the payment request, performing payment verification on the payment request to determine whether the payment request satisfies a payment withholding condition corresponding to the enterprise account; and if the payment request meets the payment withholding condition, completing the payment operation corresponding to the payment request from the enterprise account.

The payment deduction condition may include a payment deduction condition created by an enterprise user corresponding to the enterprise account bound to the employee account for the employee corresponding to the employee account. Note that the storage method of the payment withholding condition is not particularly limited in the present application.

In some instances, employees may need to obtain business approval when traveling on business. At this time, the enterprise may complete the binding operation between the enterprise and the employee through the enterprise client corresponding to the enterprise (the specific binding process is described in the following embodiments and is not described in detail here). In the binding process, the enterprise can set a plurality of payment withholding conditions for the employee through the enterprise account, so that the enterprise account replaces the employee account to complete the payment for public payment under the condition that the triggered payment for public payment meets the payment withholding conditions.

When the payment withholding condition is obtained, the payment withholding condition corresponding to the enterprise account bound to the employee account may be determined based on a correspondence between the payment withholding condition and the enterprise account that is maintained in advance. The correspondence may be maintained during the binding operation between the enterprise and the employee (a specific maintenance process is described in the following embodiments, and is not described in detail here).

After obtaining the payment withholding condition, the server may verify the payment request according to the payment withholding condition.

In this step, it may be determined whether the payment request satisfies the obtained payment withholding condition. If the payment request meets the acquired payment deduction condition, the payment request can be considered to be verified. Otherwise, the verification may be considered to be failed. It can be understood that different payment withholding conditions correspond to different verification modes. The specific description of the verification method is described in the following embodiments, and is not detailed here.

If the verification is passed, the payment operation corresponding to the payment request can be completed from the enterprise account.

In some examples, the enterprise account may include employee sub-accounts assigned to different employees. The employee sub-account may include available funds or available credit allocated by the enterprise for the employee.

At this time, the payment operation may be completed through an employee sub-account corresponding to the employee among a plurality of employee sub-accounts included in the enterprise account.

By the method, consumption records of all employees can be counted conveniently, and an enterprise can audit conveniently.

In the payment method, whether the payment request initiated by the employee account meets the set payment withholding condition or not is determined, and the enterprise replaces the employee to pay when the request meets the payment withholding condition, so that a fund trust mechanism is established between the enterprise and the employee, the enterprise bound by the employee replaces the payment after the employee initiates the payment request, the due-to-public payment process is simplified, the burden of the employee and financial staff of the enterprise is reduced, and the due-public payment efficiency is improved.

In some examples, before initiating the payment request, the employee may select, via the corresponding applet, an option to make a payment over behalf of the binding enterprise. And then, initiating the payment request based on the two-dimensional code or code scanning function provided by the applet.

For example, an employee client corresponding to an employee may include an applet corresponding to a business payment. The employee can select the enterprise to carry out the generation payment through the applet, and the two-dimensional code provided by the merchant is scanned through the code scanning function used by the applet, so that the payment request is initiated. After receiving the payment request, the server may execute the step of S104 to complete the corporate payment.

In some examples, in order to facilitate flexible selection of the payment method for the employee, a withholding option corresponding to the enterprise account may be output to the employee after the payment verification is passed, so that the employee can flexibly select whether to make a payment for the enterprise.

In some examples, after determining that the payment request satisfies the payment withholding condition corresponding to the enterprise account, sending an indication message to an employee client corresponding to the employee account to trigger the employee client to output a withholding option corresponding to the enterprise account. And then receiving a payment confirmation instruction sent by the employee client in response to the triggering operation of the employee on the withholding option. And finally, responding to the payment confirmation instruction, and completing the payment operation corresponding to the payment request from the enterprise account.

In some examples, the indication message may include a verification result that the server side passes the verification. And the verification result comprises an enterprise account identifier corresponding to the payment deduction terms passing the verification. At this time, after receiving the instruction message, the employee client may output a withholding option corresponding to the enterprise account indicated by the enterprise account identifier.

In some examples, the indication message may include a preset signal sent by the server to the employee client after the server passes the verification. The preset signal can represent different enterprise accounts. At this time, after receiving the preset information, the employee client may output a withholding option corresponding to the enterprise account represented by the preset signal.

The deduction substitute option is specifically an enterprise deduction substitute option which is preset and corresponds to the enterprise account. After the employee selects the withholding option, the enterprise indicated by the withholding option can complete the payment instead of the employee. It should be noted that, when the withholding option is presented, names such as enterprise withholding, due payment, and the like may be presented. The method for displaying the withholding option is not particularly limited in the present application.

In some examples, to promote compatibility, facilitating user selection to promote user experience, the above-described withholding options may be presented in a payment confirmation interface.

In practical application, after the server verifies the payment request, an indication message may be sent to the employee client corresponding to the employee account to trigger the employee client to jump to a payment confirmation interface, and a withholding option corresponding to the enterprise account is output in the payment confirmation interface.

The payment confirmation instruction may be specifically constructed by the employee client receiving the trigger operation of the employee for the withholding option.

In practical application, the employee may execute an operation, such as clicking or touching, in an area corresponding to the withholding option to trigger the employee client to construct a payment confirmation instruction, and send the payment confirmation instruction to the server.

For example, after the employee identifies the discount option output by the employee client, a selection operation such as clicking may be performed on the discount option. And after receiving the selection operation signal, the employee client can construct the payment confirmation instruction and send the payment confirmation instruction to the server. It should be noted that the present application does not limit the specific structure of the payment confirmation instruction. It is understood that the employee may also perform security verification (e.g., face recognition, fingerprint recognition, password verification) operations when selecting the surrogate option, which will not be described in detail herein.

After receiving the payment confirmation instruction, the server may respond to the payment confirmation instruction to complete the payment operation corresponding to the payment request from the enterprise account.

In some examples, in order to facilitate the user or the enterprise to perform the bill inquiry or the bill verification, the payment method further includes generating a bill for payment corresponding to the payment operation after the payment is completed. And then, synchronizing the payment bill to the employee account and/or the enterprise account so as to perform bill inquiry or bill verification.

In this step, after the payment is completed, the server may generate a bill indicating the payment process according to the information of the payment application, the fund payer, the fund payee, the payment time, and the like indicated by the payment request. After the bill is generated, the bill can be stored in a local or remote server of the client so that the payment staff or the binding enterprise can inquire the bill through the account of the payment staff or the binding enterprise.

In some examples, after generating the bill, an identification indicating whether the bill was revoked may also be set for the bill.

The identification state of the bill may be set to an unchecked state when the bill is just generated. When a payer obtains a consumption certificate (e.g., an invoice or receipt), the payer, or a financial staff of a binding enterprise, may initiate a checkout operation on the bill based on the consumption certificate. After the verification operation is completed for the bill, the identification state of the bill can be set to a verified state.

In this embodiment, if the verification result of the verification is that the verification result is passed, a bill for indicating a payment process is generated according to the payment request, so that a bill verification and cancellation mechanism is provided for the employee and the enterprise by performing bill inquiry or bill verification and cancellation through the enterprise account and/or the employee account, thereby facilitating the employee or the corporate financial staff to perform bill verification and cancellation.

In some examples, the bill for payment may be synchronized to an applet associated with the employee account and/or the enterprise account in order to facilitate the employee and enterprise user querying the bill.

The applet may be an applet developed for an employee or an enterprise and loaded on a client.

In some examples, the enterprise and the employee need to be bound in the server before the payment method is executed. After binding is completed, the enterprise can complete the payment on behalf of the employee.

Referring to fig. 2, fig. 2 is a flowchart illustrating a method of binding according to the present application.

As shown in fig. 2, the binding method may include:

s202, receiving a binding request initiated by an enterprise user corresponding to the enterprise account through an enterprise client; the binding request comprises the employee account and an enterprise account bound with the employee account; and the enterprise user corresponding to the enterprise account sets payment withholding conditions for the staff corresponding to the staff account.

The binding request is specifically a request initiated by the enterprise client to the server based on the binding operation of the enterprise. And part of the information of the binding request is used for indicating the employee account, the enterprise account bound with the employee account and the payment withholding condition set for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account.

In some examples, when the enterprise needs to perform a binding operation with the target employee, the enterprise account may be logged into the enterprise client corresponding to the enterprise. After logging in the enterprise account, the employee account information of the employee to be bound and the payment withholding condition set for the employee can be input into the enterprise account to perform relevant binding operation. After receiving the binding operation, the enterprise client may generate a binding request based on the binding operation, and send the binding request to the server.

After receiving the binding request, the server may bind the enterprise account with the employee account, and store a corresponding relationship between the employee account, the enterprise account, and the payment withholding condition.

Therefore, the binding of the employee account and the enterprise account can be completed in the server.

In some examples, in order to facilitate the confirmation of the binding information by the employee, the server, after receiving the binding request, may execute S204, in response to the binding request, initiate a binding confirmation request to the employee client, and after receiving a confirmation response sent by the employee client to the binding confirmation request, bind the enterprise account with the employee account, and store the corresponding relationship between the employee account, the enterprise account, and the payment withholding condition.

The binding confirmation request is specifically a request which is sent to a business client corresponding to the employee to be bound by the server and is used for confirming whether the employee to be bound is willing to bind with the enterprise. For example, the binding acknowledgement request may be presented by the service client in an optional manner. After receiving the binding confirmation request, the employee to be bound can interactively select, confirm or deny the employee to the service client. And after receiving the confirmation response, the server can bind the enterprise account with the employee account and store the corresponding relationship among the employee account, the enterprise account and the payment withholding condition.

And the binding of the enterprise account and the employee account is completed. After the binding is completed, when the employee initiates a payment request, the payment withholding condition corresponding to the employee account may be acquired based on the correspondence between the stored payment withholding condition and the enterprise account, and a subsequent verification payment operation may be performed.

In some examples, the enterprise may set flexible payment withholding conditions for the employees to adapt to different business requirements.

In some examples, the business requirements may include requiring employees to complete enterprise payments only if the employees make public payment applications within a specified validity period and trusted limit. At this time, the payment withholding condition may include a first payment amount set by the enterprise for the employee and a validity period of the first payment amount.

When the binding operation is carried out, the enterprise can set the payment withholding condition for the employee through the enterprise account.

At this time, when the payment request is verified according to the payment withholding condition, the server may determine whether the occurrence time of the payment request is within the validity period of the first payment amount set in the payment withholding condition.

And if the occurrence time is within the validity period, further determining whether the amount of the funds to be transferred indicated by the payment request reaches a first payment limit set in the payment withholding condition.

If the fund amount to be transferred does not reach the first payment amount, the verification result is determined to be passed.

In this embodiment, the enterprise may verify the payment request according to the payment withholding condition, and determine that the verification result is passed when the occurrence time of the payment request is within the validity period and the amount of funds to be transferred of the payment request is within the first payment amount, so that the business requirement may be satisfied by setting the payment withholding condition for the employee.

For example, the first payment amount is 500, and the validity period is within 10 days after the payment rule is set. In this embodiment, the employee is allowed to apply for the official payment only if the employee's spending amount is within 500 and the employee's spending date is within the validity period.

In some examples, the business requirement may include that the employee is required to complete the enterprise payment substitute only when the employee applies for the official payment under a specified payment substitution scenario. At this time, the payment withholding condition may include a payment withholding scenario set by the enterprise for the employee. The payment withholding scene can represent the payment use of the staff. For example, the payment withholding scenario described above may characterize the employee as accommodation for this payment use.

At this time, when the payment request is verified according to the payment withholding condition, the server may determine whether a payment scenario corresponding to the payment request matches the payment withholding scenario.

And if the payment scene corresponding to the payment request is matched with the payment withholding scene, determining that the verification result is passed.

In this embodiment, the enterprise may verify the payment request by including the payment withholding condition, and determine that the verification result is passed when the payment scenario indicated by the payment request matches the payment withholding scenario, so that the business requirement may be satisfied by setting the payment withholding condition for the employee.

For example, the payment withholding scenario is accommodation. In this embodiment, the employee is only allowed to make a payment on behalf of the bound enterprise if he initiates a request for a business payment for lodging.

In some examples, the business requirements may include requiring that employees complete corporate payments only upon initiation of a payment request to an appointed payee of the appointment. In this case, the payment withholding condition may include a designated payee set by the enterprise for the employee.

In this case, when the payment request is verified according to the payment withholding condition, the server may determine whether the payee indicated by the payment request matches the designated payee.

And if the payee is matched with the specified payee, determining that the verification result is passed.

In this embodiment, the enterprise may verify the payment request by including the payment withholding condition, and determine that the verification result is passed when the payee indicated by the payment request matches the specified payee, so that the business requirement may be satisfied by setting the payment withholding condition for the employee.

For example, the designated payee is an account of enterprise a. In this embodiment, the employee is only allowed to use the post payment when initiating the payment order for payment with business a as described above.

In some examples, the service requirement may include that when an employee is required to perform a consumption action with a specified payment withholding scenario or with a specified payee, a public payment due application needs to be performed within a specified validity period and a trusted amount corresponding to the preset payee, so as to complete enterprise withholding. At this time, the payment withholding condition may include a second payment withholding amount corresponding to the payment withholding scene or the designated payee set by the enterprise for the employee, and a validity period of the second payment withholding amount.

At this time, when the payment request is verified according to the payment withholding condition, if the payment scene corresponding to the payment request is matched with the payment withholding scene, whether the occurrence time of the payment request is within the validity period of a second payment withholding limit corresponding to the payment withholding scene is further determined; if the occurrence moment is within the validity period, further determining whether the payment amount corresponding to the payment request reaches the second payment withholding amount corresponding to the payment withholding scene; if yes, determining that the payment verification is passed; alternatively, the first and second liquid crystal display panels may be,

if the payee corresponding to the payment request is matched with the appointed payee, further determining whether the occurrence time of the payment request is within the validity period of a second payment withholding amount corresponding to the appointed payee; if the occurrence time is within the validity period, further determining whether the payment amount corresponding to the payment request reaches the second payment withholding amount corresponding to the appointed payee; and if so, determining that the payment verification is passed.

In this embodiment, the enterprise may verify the payment request by including the payment deduction replacement condition, and determine that the verification result is passed when the payment scenario corresponding to the payment request matches the payment deduction replacement scenario or the corresponding payee matches the designated payee, the occurrence time indicated by the payment request is within the validity period, and the amount of funds to be transferred indicated by the payment request is within the second payment amount. Therefore, the service requirement can be met by setting the payment withholding condition for the staff.

For example, the designated payee is enterprise B. The second amount is 300, and the validity period is within 10 days after the payment rule is set. In this embodiment, when the employee and the enterprise B perform the consuming action, the employee is allowed to apply for the payment only if the consumption amount of the employee is within 300 and the consumption date of the employee is within the validity period.

In some examples, if a payment scenario corresponding to the payment request matches the payment withholding scenario, determining a target sub-account corresponding to the payment scenario included in the payment withholding condition from among sub-accounts included in the enterprise account;

completing the payment operation corresponding to the payment request from the target sub-account;

or the like, or, alternatively,

if the payee corresponding to the payment request is matched with the designated payee, determining a target sub-account corresponding to the payee in the sub-accounts included in the enterprise account;

and completing the payment operation corresponding to the payment request from the target sub-account.

In this embodiment, when the employee needs to pay funds in the designated payment withholding scenario or the designated payee, the employee can complete payment through the sub-account corresponding to the designated payment withholding scenario or the designated payee, so that the enterprise can be dedicated for the special money.

It should be noted that the above payment deduction conditions can be flexibly combined and set according to actual business requirements, and besides several payment deduction conditions listed in this application, other conceivable payment deduction conditions also belong to the protection scope of this application.

In some examples, the enterprise is only willing to pay a certain amount of public fee for the employee, and the extra fee is required to be borne by the employee. At this time, the payment withholding condition may include a fund amount that the enterprise may pay for the employee in a preset time period.

The preset time period can be set by an enterprise. For example, the preset time period may be 0 to 23 to 59 minutes per day.

The fund limit can indicate the limit which can be paid by the enterprise for the staff in a specified payment scene. For example, the fund amount is 15 yuan, and the payment scenario is a meal fee. At this time, the payment withholding condition can be interpreted that the enterprise can pay 15 yuan of meal fee with the staff every day.

At this time, when the payment request is verified according to the payment withholding condition, the server may determine whether the payment purpose indicated by the payment request matches a specified payment scenario set in the payment withholding condition.

If the payment purpose is matched with the appointed payment scene, inquiring the fund limit corresponding to the appointed payment scene, and returning the fund limit as a verification result to the employee client so as to remind the employee of the fund limit which can be born by the enterprise in the public payment. Other remaining amounts may be selected by the employee for other payment methods. The other payment method may be a payment by another enterprise or a payment by an employee, and is not particularly limited herein.

For example, the payment withholding condition set by Enterprise A for employee B is that Enterprise A allows employee B to pay a 15-dollar meal per day. Assume that the employee initiated payment request indicates a use for a meal fee with a tariff amount of 20 dollars. At this time, the enterprise a can only make a 15-yuan payment with the employee B, and the remaining 5-yuan needs to be paid by the employee in another payment method.

In some examples, the employee account may be bound to multiple enterprise accounts. At this time, in order to support the employee to select the target enterprise account by himself to perform enterprise withholding, when the server sends an instruction message to the employee client corresponding to the employee account to trigger the employee client to output the withholding option corresponding to the enterprise account, a verification passing result may be returned to the employee client corresponding to the employee account to trigger the employee client to output the withholding options corresponding to the enterprise accounts.

In this step, the server constructs an instruction message based on the enterprise account corresponding to the payment withholding condition that is verified, and returns the constructed instruction message to the employee client. And the indication message indicates the enterprise account identifier corresponding to the payment withholding condition which passes the verification. After receiving the indication message sent by the server, the employee client may parse the indication message, and output, based on the parsed multiple enterprise account identifiers, discount options respectively corresponding to the enterprise accounts indicated by the multiple enterprise account identifiers.

The employee can select and operate the deduction option corresponding to the target enterprise account needing to be paid for on the employee client. The employee client can respond to the selection operation, generate a payment confirmation instruction, and send the instruction to the server.

After receiving the payment confirmation instruction, the server may determine, in response to the payment confirmation instruction, a target enterprise account corresponding to the target withholding option.

After determining the target business account, a payment operation corresponding to the payment request may be completed from the target business account.

The following embodiments are described in conjunction with specific payment scenarios.

Referring to fig. 3, fig. 3 is a schematic view of a payment scenario shown in the present application.

As shown in fig. 3, the open arrows indicate that employee C needs to make an equity purchase and therefore a payment to service provider merchant E. The solid arrows represent the actual payment flow for employee C. Namely employee C completes the enterprise payment through the enterprise account corresponding to enterprise D bound to employee C.

In the payment scenario illustrated in fig. 3, two steps can be separated: firstly, an enterprise D and an employee C need to be bound; second, a payment request is initiated by employee C to complete the corporate surcharge.

The above two steps are described separately in two parts below.

First, please refer to fig. 4, wherein fig. 4 is a schematic flow chart of a binding method shown in the present application.

As shown in fig. 4, enterprise D needs to bind with employee C. Enterprise D may perform binding operations with its corresponding enterprise client. When editing the binding information, the account information of the staff to be bound can be set as the binding information, the payment withholding condition is set as the payment withholding condition, and the staff C can carry out enterprise withholding for dining, lodging, transportation and business banquet within 10 days of the day of setting the payment withholding condition; wherein the accommodation can only select merchant E. The payment withholding condition further comprises that the employee has 2000 spending limit within the 10 days.

After receiving the binding operation of the enterprise D, the enterprise client may execute S402, construct a binding request between the enterprise D and the employee C, and send the binding request to the server.

After receiving the binding request, the server may execute S404 to send a binding confirmation request to the employee client corresponding to the employee C.

And the employee client can display the binding confirmation request to the employee C after receiving the binding confirmation request.

After receiving the binding confirmation request, the employee C may perform a confirmation operation on the employee client.

After receiving the confirmation operation of the employee C, the employee client may execute S406 to construct a confirmation response, and return the confirmation response to the server.

And after receiving the confirmation response, the server can bind the enterprise account with the employee account and store the corresponding relationship among the employee account, the enterprise account and the payment withholding condition.

After the binding operation is completed, the server may execute S408, and return a binding completion message to the enterprise client and/or the employee client to notify that the enterprise D has completed binding with the employee C.

Thus, the binding work of the enterprise D and the employee C is completed.

Second, please refer to fig. 5, fig. 5 is a schematic diagram illustrating a payment process according to the present application.

When the employee C needs to stay at the merchant E, the corresponding cash register of the merchant E can be scanned through the terminal device carrying the employee client, and therefore the payment order provided by the merchant E is obtained. Assume that the payment amount is 200.

As shown in fig. 5, after obtaining the payment order, the employee client may execute S502, generate a payment request, and send the payment request to a server.

After receiving the payment request, the server may execute S504 to obtain, locally or from a remote server, a payment withholding condition corresponding to the enterprise account bound to the employee C account, which is stored during the binding operation. And after the payment deduction condition is obtained, the payment request can be verified according to the payment deduction condition.

In this embodiment, the payment withholding condition bound to the account of the employee C includes that the employee C can pay for the enterprise for dining, lodging, transportation, and business banquet within 10 days from the date of setting the payment withholding condition; wherein the accommodation can only select merchant E. The payment withholding condition further comprises that the employee has 2000 spending limit within the 10 days. Therefore, when the payment request is verified based on the obtained payment withholding condition, all payment information carried by the payment request meets the payment withholding condition, so that the payment request meets the payment withholding condition.

After the payment request verification is completed, the server may execute S506, obtain an enterprise D account with the payment withholding condition, package the account into an instruction message, and send the instruction message to the employee client. Alternatively, a bill may be generated from the payment request and stored for an employee or business to query or verify.

After receiving the verification result information, the employee client may execute S508, and determine the enterprise account information included in the verification result in response to the indication message.

In this example, the employee client will obtain account information for enterprise D.

After the employee client acquires the account information of the enterprise D, a withholding option corresponding to the enterprise D can be generated based on the account information of the enterprise D, and the withholding option is displayed to the employee C through a terminal display screen.

The employee C can perform selection operation on the employee client, and select and determine the withholding option corresponding to the enterprise D to perform enterprise withholding. The selection operation may further include a security verification operation such as a password input by the employee C, and is not limited herein.

After receiving the selection operation, the employee client may execute S510, construct a payment confirmation instruction, and send the payment confirmation instruction to the server. It should be noted that the payment confirmation instruction may further include information such as security verification information for ensuring secure payment, which is not limited herein.

After receiving the payment confirmation instruction, the server may execute S512, determine the enterprise account information indicated by the payment confirmation instruction, and complete order payment by using the determined enterprise account instead of the employee.

In this example, since the business account is a business D account, order payment can be completed through the business D account instead of employee C.

In some examples, in executing S512, the server may send an order payment-for-replacement confirmation request to the enterprise account. After receiving the order payment substituting request, the enterprise account can make a relevant display to the enterprise so that the enterprise can make a selection whether to substitute payment. If the enterprise chooses to confirm the order payment, the enterprise can replace the staff to complete the order payment; otherwise, the payment-for-others flow is terminated and the employee enterprise is informed of the failure of payment-for-others.

Thus, the enterprise payment is completed.

In the method, on one hand, whether a payment request initiated by an employee account meets a set payment withholding condition is determined, and an enterprise replaces an employee to pay when the request meets the payment withholding condition, so that a fund trust mechanism is established between the enterprise and the employee, the enterprise bound by the employee replaces the employee to complete payment after the employee initiates the payment request, the due-to-public-payment flow is simplified, the burden of the employee and financial staff of the enterprise is reduced, and the due-public-payment efficiency is improved.

On the other hand, a mechanism for setting payment withholding conditions for the employees by the enterprise is provided, so that the enterprise can set flexible payment withholding conditions for the employees so as to adapt to different business requirements.

For example, in an employee benefit scenario, a business purchased 300 purchase tickets for an employee at merchant F. At this time, the enterprise may set the amount for its employee to 300, and designate the payee as the payment rule of the merchant F, so that the employee can enjoy the amount of 300 at the merchant F.

In a second aspect of the present application, a payment method is presented. The method is applied to the employee client.

The payment method may include:

It will be appreciated that an understanding of the payment method may be had with reference to any of the embodiments described above and will not be described in detail herein.

In the method, the payment method applied to the employee client is provided, so that after the employee conducts consumption, enterprise payment can be achieved through interaction with the employee client, the procedure of payment due to public payment is simplified, and the payment efficiency is improved.

In some examples, in order to improve flexibility of the employee in making a selection, the server may send an instruction message to the employee client when the payment request satisfies the payment withholding condition. And then, the employee server may receive an instruction message sent by the server when determining that the payment request satisfies the payment withholding condition corresponding to the enterprise account.

And then, responding to the indication message, outputting a withholding option corresponding to the enterprise account, and responding to the triggering operation of the employee on the withholding option to initiate a payment confirmation instruction to the server, so that the server responds to the payment confirmation instruction to complete the payment operation corresponding to the payment request from the enterprise account.

By the scheme, the withholding option can be provided for the staff after the payment verification is passed, so that the staff can flexibly select whether to carry out enterprise withholding or not.

In some examples, in order to promote convenience in displaying the withholding option and facilitate user selection, when the employee client outputs the withholding option corresponding to the enterprise account in response to the indication message, the employee client may jump to a payment confirmation interface in response to the indication message and output the withholding option corresponding to the enterprise account in the payment confirmation interface.

In a third aspect of the present application, a payment method is presented. The method is applied to the enterprise client.

The payment method may include:

responding to a binding operation performed by an enterprise through an enterprise account, and initiating a binding request to a server, so that on one hand, the server executes the binding method shown in any one of the embodiments; on the other hand, after the enterprise account and the employee account complete the binding operation, the employee client corresponding to the employee account executes the payment method as shown in any one of the foregoing embodiments.

In the method, the enterprise can finish the binding with the staff through the enterprise client by providing the payment method applied to the enterprise client, so that the staff can realize enterprise payment by interacting with the staff client after the consumption behavior occurs, the procedure of payment due to public payment is simplified, and the payment efficiency is improved.

Corresponding to any of the above embodiments, the present application further provides a payment device applied to the server.

Please refer to fig. 6, fig. 6 is a schematic structural diagram of a payment apparatus shown in the present application.

As shown in fig. 6, the apparatus 600 includes:

a receiving module 610 that receives a payment request; the payment request comprises an account identifier of an employee account needing payment operation; the employee account is bound with an enterprise account for payment deduction;

a verification and payment module 620, configured to perform payment verification on the payment request in response to the payment request, so as to determine whether the payment request satisfies a payment withholding condition corresponding to the enterprise account; if the payment request satisfies the payment deduction condition,

In some embodiments, the verification and payment module 620 specifically includes:

after determining that the payment request meets the payment withholding condition corresponding to the enterprise account, sending an indication message to an employee client corresponding to the employee account to trigger the employee client to output a withholding option corresponding to the enterprise account;

receiving a payment confirmation instruction sent by the employee client in response to the trigger operation of the employee for the withholding option;

and responding to the payment confirmation instruction, and completing the payment operation corresponding to the payment request from the enterprise account. In some embodiments, the verification and payment module 620 specifically includes:

and sending an indication message to the employee client corresponding to the employee account to trigger the employee client to jump to a payment confirmation interface, and outputting a withholding option corresponding to the enterprise account in the payment confirmation interface.

In some embodiments, the payment request includes a payment request initiated by the employee client or a payment request initiated by a payee client corresponding to the payee account.

In some of the illustrated embodiments, the apparatus 600 further comprises:

the generation module is used for generating a payment bill corresponding to the payment operation after the payment is finished;

and the synchronization module synchronizes the payment bill to the employee account and/or the enterprise account so as to perform bill inquiry or bill verification and cancellation.

In some illustrated embodiments, the synchronization module specifically includes:

synchronizing the bill for payment to an applet associated with the employee account and/or the enterprise account.

In some illustrated embodiments, the verification and payment module 620 specifically includes:

responding to the payment request, and acquiring a payment withholding condition corresponding to an enterprise account bound with the account identifier of the employee account included in the payment request;

and carrying out payment verification on the payment request based on the payment withholding condition.

In some embodiments shown, the payment withholding condition comprises: the enterprise user corresponding to the enterprise account sets a first payment withholding amount for the staff corresponding to the staff account and the validity period of the first payment withholding amount;

the verification and payment module 620 includes:

determining whether the occurrence time of the payment request is in the valid period of the first payment withholding amount set in the payment withholding condition;

if the occurrence time is within the validity period, further determining whether the payment amount corresponding to the payment request reaches the first payment withholding amount;

and if the payment amount does not reach the first payment withholding amount, determining that the verification result is passed.

In some illustrated embodiments, the payment withholding condition includes a payment withholding scenario that is set for an employee corresponding to the employee account by an enterprise user corresponding to the enterprise account;

the verification and payment module 620 includes:

determining whether a payment scene corresponding to the payment request is matched with the payment withholding scene;

In some illustrated embodiments, the payment withholding condition includes a designated payee set by the enterprise user corresponding to the enterprise account for the employee corresponding to the employee account;

the verification and payment module 620 includes:

determining whether a payee corresponding to the payment request is matched with the designated payee;

and if the payee corresponding to the payment request is matched with the appointed payee, determining that the verification result is passed.

In some embodiments shown, the payment withholding condition comprises: the enterprise user corresponding to the enterprise account sets a second payment withholding amount corresponding to a payment withholding scene or an appointed payee and the validity period of the second payment withholding amount for the employee corresponding to the employee account;

the verification and payment module 620 includes:

if the payment scene corresponding to the payment request is matched with the payment withholding scene, further determining whether the occurrence time of the payment request is within the validity period of a second payment withholding amount corresponding to the payment withholding scene; if the occurrence time is within the validity period, further determining whether the payment amount corresponding to the payment request reaches the second payment withholding amount corresponding to the payment withholding scene; if yes, determining that the payment verification is passed; alternatively, the first and second liquid crystal display panels may be,

In some embodiments, the verification and payment module 620 includes:

if the payment scene corresponding to the payment request is matched with the payment withholding scene, determining a target sub-account corresponding to the payment scene included in the payment withholding condition in the sub-accounts included in the enterprise account;

or the like, or, alternatively,

In some embodiments shown, the employee account is bound to a plurality of enterprise accounts; the payment confirmation instruction is a payment confirmation instruction sent by the employee client in response to the trigger operation of the employee on a target withholding option in withholding options respectively corresponding to the enterprise accounts;

the verification and payment module 620 includes:

returning a verification passing result to the employee client corresponding to the employee account to trigger the employee client to output withholding options corresponding to the enterprise accounts respectively;

responding to the payment confirmation instruction, and determining a target enterprise account corresponding to the target withholding option;

and completing the payment operation corresponding to the payment request from the target enterprise account.

In some of the illustrated embodiments, the apparatus 600 further comprises:

the binding module is used for receiving a binding request initiated by an enterprise user corresponding to the enterprise account through an enterprise client; the binding request comprises the employee account, an enterprise account bound with the employee account and a payment withholding condition set for an employee corresponding to the employee account by an enterprise user corresponding to the enterprise account;

Corresponding to any embodiment, the application further provides a payment device applied to the employee client.

The above apparatus 700 includes:

the sending module 710, in response to a payment operation performed by an employee through an employee account, initiates a payment request to a server, so that the server performs payment verification on the payment request in response to the payment request, so as to determine whether the payment request satisfies a payment withholding condition corresponding to an enterprise account included in the payment request, and when the payment request satisfies the payment withholding condition, completes the payment operation corresponding to the payment request from the enterprise account.

Corresponding to any of the above embodiments, the present application further proposes a payment apparatus 800 applied to an enterprise client, including:

a sending module 810, configured to initiate a binding request to a server in response to a binding operation performed by an enterprise through an enterprise account, so that, on one hand, the server executes a binding method as shown in any one of the foregoing embodiments; on the other hand, after the enterprise account and the employee account complete the binding operation, the employee client corresponding to the employee account executes the payment method as shown in any one of the foregoing embodiments.

The embodiment of the payment device shown in the application can be applied to electronic equipment. Accordingly, the present application discloses an electronic device, which may comprise: a processor.

A memory for storing processor-executable instructions.

Wherein the processor is configured to invoke the executable instructions stored in the memory to implement the payment method as shown in any of the above embodiments.

Referring to fig. 7, fig. 7 is a schematic diagram of a hardware structure of an electronic device shown in the present application.

As shown in fig. 7, the electronic device may include a processor for executing instructions, a network interface for making network connections, a memory for storing operation data for the processor, and a non-volatile memory for storing instructions corresponding to the image processing apparatus.

The embodiment of the payment apparatus may be implemented by software, or may be implemented by hardware, or a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. In terms of hardware, in addition to the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 7, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to the actual function of the electronic device, which is not described again.

It is understood that, in order to increase the processing speed, the payment device corresponding instruction may also be directly stored in the memory, which is not limited herein.

The present application proposes a computer-readable storage medium storing a computer program for executing the payment method shown in any one of the above embodiments.

One skilled in the art will recognize that one or more embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present application may take the form of a computer program product embodied on one or more computer-usable storage media (which may include, but are not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

"and/or" in this application means having at least one of the two, for example, "a and/or B" may include three schemes: A. b, and "A and B".

The embodiments in the present application are described in a progressive manner, and the same and similar parts among the embodiments can be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, as for the data processing apparatus embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the partial description of the method embodiment for relevant points.

The foregoing description of specific embodiments of the present application has been presented. Other embodiments are within the scope of the following claims. In some cases, the acts or steps recited in the claims can be performed in an order different than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Embodiments of the subject matter and functional operations described in this application may be implemented in the following: digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware that may include the structures disclosed in this application and their structural equivalents, or combinations of one or more of them. Embodiments of the subject matter described in this application can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a tangible, non-transitory program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode and transmit information to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

The processes and logic flows described in this application can be performed by one or more programmable computers executing one or more computer programs to perform corresponding functions by operating on input data and generating output. The processes and logic flows described above can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Computers suitable for executing computer programs may include, for example, general and/or special purpose microprocessors, or any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. The essential components of a computer can include a central processing unit for implementing or executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer does not necessarily have such a device. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

Computer-readable media suitable for storing computer program instructions and data can include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disk or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

Although this application contains many specific implementation details, these should not be construed as limiting the scope of any disclosure or of what may be claimed, but rather as merely describing features of particular disclosed embodiments. Certain features that are described in this application in the context of separate embodiments can also be implemented in combination in a single embodiment. In another aspect, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Further, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.

The above description is intended only to serve as a preferred embodiment of one or more embodiments of the present application, and should not be taken as limiting the one or more embodiments of the present application, as any modification, equivalent replacement, improvement or the like made within the spirit and principle of the one or more embodiments of the present application shall be included in the scope of protection of the one or more embodiments of the present application.

Claims

1. A payment method is applied to a server side; the server maintains the corresponding relation between the employee account, the enterprise account and the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the method comprises the following steps:

receiving a payment request; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee;

responding to the payment request, and determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the corresponding relation;

performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account;

and if the payment request meets the payment withholding condition, the enterprise account replaces the employee to pay for the payment order so as to complete the payment operation corresponding to the payment request.

2. The method of claim 1, the making a payment for the payment order from the business account in place of the employee to complete the payment operation corresponding to the payment request if the payment request satisfies the payment withholding condition, comprising:

if the payment request meets the payment withholding condition, sending an indication message to an employee client corresponding to the employee account to trigger the employee client to output a withholding option corresponding to the enterprise account;

receiving a payment confirmation instruction sent by the employee client in response to the trigger operation of the employee for the withholding option; in response to the payment confirmation instruction, making a payment for the payment order from the enterprise account in place of the employee to complete the payment operation corresponding to the payment request.

3. The method of claim 2, the sending an indication message to an employee client corresponding to the employee account to trigger the employee client to output a withholding option corresponding to the enterprise account, comprising:

and sending an indication message to the employee client corresponding to the employee account so as to trigger the employee client to skip to a payment confirmation interface, and outputting a withholding option corresponding to the enterprise account in the payment confirmation interface.

4. The method of claim 1, the payment request comprising a payment request initiated by the employee client or a payment request initiated by a payee client corresponding to a payee account.

5. The method of claim 1, further comprising:

after the payment is completed, generating a payment bill corresponding to the payment operation;

synchronizing the bill for payment to the employee account and/or the enterprise account for bill inquiry or bill verification.

6. The method of claim 5, synchronizing the bill for payment to the employee account and/or the enterprise account, comprising: synchronizing the bill for payment to an applet associated with the employee account and/or the enterprise account.

7. The method of claim 1, the verifying payment in response to the payment request for the payment request comprising:

8. The method of claim 7, the payment deduction condition comprising: the enterprise user corresponding to the enterprise account sets a first payment withholding amount for the employee corresponding to the employee account and the validity period of the first payment withholding amount;

the payment verification of the payment request based on the payment withholding condition comprises the following steps:

9. The method of claim 7, wherein the payment withholding condition comprises a payment withholding scenario set by an enterprise user corresponding to the enterprise account for an employee corresponding to the employee account;

10. The method of claim 7, wherein the payment withholding condition comprises a designated payee set by an enterprise user corresponding to the enterprise account for an employee corresponding to the employee account;

determining whether a payee corresponding to the payment request is matched with the specified payee;

and if the payee corresponding to the payment request is matched with the specified payee, determining that the verification result is passed.

11. The method of claim 7, the paying a withholding condition comprising: a second payment withholding amount corresponding to the payment withholding scene or the appointed payee, and the validity period of the second payment withholding amount; the payment withholding condition comprises a condition set for an employee corresponding to the employee account by an enterprise user corresponding to the enterprise account;

the method further comprises the following steps:

if the payee corresponding to the payment request is matched with the appointed payee, further determining whether the occurrence time of the payment request is within the validity period of a second payment withholding amount corresponding to the appointed payee; if the occurrence moment is within the validity period, further determining whether the payment amount corresponding to the payment request reaches the second payment withholding amount corresponding to the appointed payee; and if so, determining that the payment verification is passed.

12. The method of claim 11, the completing the payment operation corresponding to the payment request from the business account comprising:

completing a payment operation corresponding to the payment request from the target sub-account;

or the like, or, alternatively,

13. A method according to any of claims 2-11, wherein the employee account is bound to a plurality of enterprise accounts; the payment confirmation instruction is a payment confirmation instruction sent by the employee client in response to the trigger operation of the employee on a target withholding option in the withholding options respectively corresponding to the enterprise accounts;

the sending of the instruction message to the employee client corresponding to the employee account to trigger the employee client to output the withholding option corresponding to the enterprise account includes:

the completing, from the enterprise account in response to the payment confirmation instruction, a payment operation corresponding to the payment request includes:

14. The method of claim 1, further comprising:

receiving a binding request initiated by an enterprise user corresponding to the enterprise account through an enterprise client; the binding request comprises the employee account and an enterprise account bound with the employee account; and the enterprise user corresponding to the enterprise account sets a payment withholding condition for the employee corresponding to the employee account;

responding to the binding request, initiating a binding confirmation request to the employee client, binding the enterprise account with the employee account after receiving a confirmation response which is sent by the employee client and aims at the binding confirmation request, and storing the corresponding relation among the employee account, the enterprise account and the payment withholding condition.

15. The method of claim 1, the performing payment validation for the payment request to determine whether the payment request satisfies a payment withholding condition corresponding to the corporate account, comprising:

judging whether the payment application indicated by the payment request is matched with a preset scene included in a payment deduction condition or not, and determining that the payment request meets the payment deduction condition when the payment application indicated by the payment request is matched with the preset scene included in the payment deduction condition; the payment withholding condition comprises a payment withholding condition corresponding to the enterprise account; the payment withholding condition comprises the fund amount born by the enterprise for the employee in a preset time period and a preset scene;

if the payment request meets the payment deduction condition, completing the payment operation corresponding to the payment request from the enterprise account, wherein the payment operation comprises the following steps:

if the payment request meets the payment withholding condition, sending an indication message to an employee client corresponding to the employee account to trigger the employee client to output a withholding option corresponding to the enterprise account, and returning the fund limit to the employee client as a verification result;

and responding to the payment confirmation instruction, and completing the payment operation corresponding to the payment request according to the enterprise account and other payment modes selected by the employee.

16. A payment method is applied to an employee client; the server corresponding to the employee client maintains the corresponding relation between the employee account, the enterprise account and the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the method comprises the following steps:

responding to a payment operation carried out by an employee through an employee account, and initiating a payment request to the server so that the server responds to the payment request, and determines an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the corresponding relation; and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request, and performing payment on the payment order from the enterprise account instead of the employee to complete a payment operation corresponding to the payment request when the payment request meets the payment withholding condition; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee.

17. The method of claim 16, further comprising:

receiving an indication message sent by the server when the payment request is determined to meet the payment withholding condition corresponding to the enterprise account;

responding to the indication message, outputting a withholding option corresponding to the enterprise account, and responding to a trigger operation of the employee for the withholding option to initiate a payment confirmation instruction to the server, so that the server responds to the payment confirmation instruction to complete the payment operation corresponding to the payment request from the enterprise account.

18. The method of claim 17, the outputting, in response to the indication message, a withholding option corresponding to the enterprise account, comprising:

and responding to the indication message, jumping to a payment confirmation interface, and outputting a withholding option corresponding to the enterprise account in the payment confirmation interface.

19. A payment device is applied to a server side; the server maintains the corresponding relation between the employee account, the enterprise account and the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the device comprises:

the receiving module receives a payment request; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee;

the verification and payment module is used for responding to the payment request, determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the corresponding relation;

performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; and if the payment request meets the payment withholding condition, the enterprise account replaces the employee to pay for the payment order so as to complete the payment operation corresponding to the payment request.

20. The apparatus of claim 19, the apparatus further comprising:

the binding module is used for receiving a binding request initiated by an enterprise user corresponding to the enterprise account through an enterprise client; the binding request comprises the employee account and an enterprise account bound with the employee account; and the enterprise user corresponding to the enterprise account sets a payment withholding condition for the employee corresponding to the employee account;

21. A payment device is applied to an employee client; the server corresponding to the employee client maintains the corresponding relation between the employee account, the enterprise account and the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the device comprises:

the sending module is used for responding to payment operation of an employee through an employee account, initiating a payment request to the server so that the server responds to the payment request, and determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the corresponding relation; and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request, and performing payment on the payment order from the enterprise account instead of the employee to complete a payment operation corresponding to the payment request when the payment request meets the payment withholding condition; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee.

22. An electronic device, comprising:

a processor;

a memory for storing executable instructions corresponding to the processor;

responding to the payment request, and determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the maintained corresponding relationship among the employee account, the enterprise account and the payment withholding condition; performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; if the payment request meets the payment withholding condition, the enterprise account replaces the employee to pay for the payment order so as to complete the payment operation corresponding to the payment request; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account;

or the like, or, alternatively,

responding to a payment operation carried out by an employee through an employee account, and initiating a payment request to a server so that the server responds to the payment request, and according to a corresponding relation between an employee account, an enterprise account and a payment withholding condition maintained by the server, determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account; and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request, and performing payment on the payment order from the enterprise account instead of the employee to complete a payment operation corresponding to the payment request when the payment request meets the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee.

23. A computer-readable storage medium, the storage medium storing a computer program for performing:

responding to the payment request, and determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to the maintained corresponding relationship among the employee account, the enterprise account and the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account;

performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to the enterprise account; if the payment request meets the payment withholding condition, the enterprise account replaces the employee to pay for the payment order so as to complete the payment operation corresponding to the payment request;

or the like, or, alternatively,

responding to a payment operation carried out by an employee through an employee account, initiating a payment request to a server, so that the server responds to the payment request, and determining an enterprise account bound with the employee account and a payment withholding condition corresponding to the enterprise account according to a corresponding relation between the employee account, the enterprise account and the payment withholding condition maintained by the server; and performing payment verification on the payment request to determine whether the payment request meets a payment withholding condition corresponding to an enterprise account included in the payment request, and performing payment on the payment order from the enterprise account instead of the employee to complete a payment operation corresponding to the payment request when the payment request meets the payment withholding condition; the payment withholding condition is created for the employee corresponding to the employee account by the enterprise user corresponding to the enterprise account bound with the employee account; the payment request comprises employee account identification needing payment operation; the payment request is generated based on a payment order between the employee and a payee.