CN113822661A

CN113822661A - Payment method, device and system

Info

Publication number: CN113822661A
Application number: CN202110313729.4A
Authority: CN
Inventors: 李卫锋
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2021-03-24
Filing date: 2021-03-24
Publication date: 2021-12-21

Abstract

The embodiment of the disclosure discloses a payment method, a payment device and a payment system. One embodiment of the method comprises: receiving an initial payment resource for a resource to be paid; determining unpaid resources according to the difference value between the resources to be paid and the initial payment resources; the following payment processing steps are performed: receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful. The implementation mode realizes that the payment process of the resource to be paid is completed through two or more payments.

Description

Payment method, device and system

Technical Field

The embodiment of the disclosure relates to the technical field of computers, in particular to a payment method, a payment device and a payment system.

Background

With the rapid development and popularization of electronic commerce, it is becoming one of the hot spots of internet application. In this process, electronic payments are also being developed. Electronic payment generally refers to various transaction behaviors such as payment of money or fund transfer, in which payment information is securely transmitted between parties (such as consumers, merchants, financial institutions and the like) of a transaction through an information network to a corresponding processing institution (such as a bank and the like) by using a secure electronic means.

At present, a payment process usually includes that one party (such as a payment currency party) in a transaction selects a payment mode to pay, and another party (such as a currency receiving party) in the transaction checks whether the payment is successful or not, and returns corresponding payment result information.

In order to ensure the security of electronic payment, etc., corresponding measures are generally provided for various payment methods. For example, to circumvent some abnormal trading behavior, a single limit, a weekly trade limit, a monthly trade limit, etc. may be made. Also for example, different quota limits may be set based on the user's personal credit information, etc. Therefore, during the payment process, there may be situations where payment is limited (such as an excess of a single payment amount), and in these situations, the payment cannot be completed normally.

Disclosure of Invention

The embodiment of the disclosure provides a payment method and a payment device.

In a first aspect, an embodiment of the present disclosure provides a payment method, which is applied to a server, and the method includes: receiving an initial payment resource for a resource to be paid; determining unpaid resources according to the difference value between the resources to be paid and the initial payment resources; the following payment processing steps are performed: receiving current payment resources for unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

In a second aspect, an embodiment of the present disclosure provides a payment method, applied to a client, where the method includes: sending an initial payment resource for the resource to be paid; receiving unpaid resources, wherein the unpaid resources are determined according to the difference value between the resources to be paid and the initial payment resources; the following payment steps are performed: sending a current payment resource for the unpaid resource; receiving payment result information indicating that payment is successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, the updated unpaid resource being determined based on a difference between the unpaid resource and the current payment resource.

In a third aspect, an embodiment of the present disclosure provides a payment system, including a client and a server; the server is used for implementing the method described in the first aspect; the client is used to implement the method as described in the second aspect.

In a fourth aspect, an embodiment of the present disclosure provides a payment apparatus, applied to a server, where the apparatus includes: an initial payment resource receiving unit configured to receive an initial payment resource for a resource to be paid; a determining unit configured to determine unpaid resources according to a difference value between the resources to be paid and the initial payment resources; a payment processing unit configured to perform the following payment processing steps: receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value between the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that payment was successful.

In a fifth aspect, an embodiment of the present disclosure provides a payment apparatus, applied to a client, the apparatus including: an initial payment resource transmitting unit configured to transmit an initial payment resource for a resource to be paid; an unpaid resource receiving unit configured to receive unpaid resources, wherein the unpaid resources are determined according to a difference value between the resources to be paid and the initial payment resources; a payment unit configured to perform the following payment steps: sending a current payment resource for the unpaid resource; receiving payment result information indicating that the payment was successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, the updated unpaid resource being determined from a difference between the unpaid resource and the current payment resource.

In a sixth aspect, an embodiment of the present disclosure provides an electronic device, including: one or more processors; storage means for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the method as described in the first aspect or the second aspect.

In a seventh aspect, embodiments of the present disclosure provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a method as described in the first or second aspect.

According to the payment method, the payment device and the payment system, the initial payment resources aiming at the resources to be paid are received, the unpaid resources are calculated, then the current payment resources aiming at the unpaid resources are received to update the unpaid resources, and the payment success is determined until the updated unpaid resources are zero. Therefore, the payment process of the resource to be paid can be completed through two or more payments, so that a new payment process is added, and meanwhile, the flexibility of the payment process can be improved.

Drawings

Other features, objects, and advantages of the present disclosure will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, with reference to the accompanying drawings in which:

FIG. 1 is a diagram of an exemplary system architecture in which an embodiment of the present disclosure may be applied;

FIG. 2 is a flow diagram of one embodiment of a payment method according to the present disclosure;

FIG. 3 is a flow diagram of yet another embodiment of a payment method according to the present disclosure;

FIG. 4 is a schematic diagram of one application scenario of a payment method in accordance with an embodiment of the present disclosure;

FIG. 5 is a flow diagram of yet another embodiment of a payment method according to the present disclosure;

FIG. 6 is a timing diagram for one embodiment of a payment system according to the present disclosure;

FIG. 7 is a schematic structural diagram of one embodiment of a payment device according to the present disclosure;

FIG. 8 is a schematic structural diagram of yet another embodiment of a payment device according to the present disclosure;

FIG. 9 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.

Detailed Description

The present disclosure is described in further detail below with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.

It should be noted that, in the present disclosure, the embodiments and the features of the embodiments may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 illustrates an exemplary architecture 100 to which embodiments of the payment method or payment apparatus of the present disclosure may be applied.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves to provide a medium for communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

The

terminal devices

101, 102, 103 interact with a server 105 over a network 104 to receive or send messages or the like. Various client applications may be installed on the

terminal devices

101, 102, 103. For example, browser-like applications, search-like applications, instant messaging tools, social platforms, shopping-like applications, financial-like applications, and the like.

The

terminal apparatuses

101, 102, and 103 may be hardware or software. When the

terminal devices

101, 102, 103 are hardware, they may be various electronic devices including, but not limited to, smart phones, tablet computers, e-book readers, laptop portable computers, desktop computers, and the like. When the

terminal apparatuses

101, 102, 103 are software, they can be installed in the electronic apparatuses listed above. It may be implemented as multiple pieces of software or software modules (e.g., multiple pieces of software or software modules to provide a distributed service), or as a single piece of software or software module. And is not particularly limited herein.

The server 105 may be a server that provides various services, such as a backend server that provides support for client applications installed on the

terminal devices

101, 102, 103. The server 105 may receive the payment resource sent by the

terminal device

101, 102, 103, process the payment resource to complete payment of the resource to be paid, and return payment result information indicating whether the payment is successful to the

terminal device

101, 102, 103.

It should be noted that the payment method applied to the server provided by the embodiment of the present disclosure is generally performed by the server 105, and accordingly, the payment apparatus applied to the server is generally disposed in the server 105. Correspondingly, the payment method applied to the client provided by the embodiment of the disclosure is generally executed by the

terminal devices

101, 102, 103, and accordingly, the payment device applied to the client is generally disposed in the

terminal devices

101, 102, 103.

The server 105 may be hardware or software. When the server 105 is hardware, it may be implemented as a distributed server cluster composed of a plurality of servers, or may be implemented as a single server. When the server 105 is software, it may be implemented as multiple pieces of software or software modules (e.g., multiple pieces of software or software modules to provide distributed services), or as a single piece of software or software module. And is not particularly limited herein.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

With continued reference to fig. 2, a flow 200 of one embodiment of a payment method according to the present disclosure is shown. The payment method can be applied to a server (such as the server 105 shown in fig. 1), and specifically includes the following steps:

step 201, an initial payment resource for a resource to be paid is received.

In this embodiment, a resource may refer to various real or virtual objects that can be used for value exchange. For example, resources include, but are not limited to: items, currency (including virtual currency, online currency, etc.), services, and so forth.

The resource to be paid may refer to a resource for which payment has not been started currently. For example, the resource to be paid may be a total amount of the user's order. The initial payment resource may refer to a resource received for the first time for paying the resource to be paid. Typically, the initial payment resource is smaller than the resource to be paid.

The executing body of the payment method (such as the server shown in fig. 1, etc.) may receive the initial payment resource sent by the client (such as the

terminal devices

101, 102, 103, etc. shown in fig. 1). Specifically, the client may display information indicating the resource to be paid, and send an initial payment resource for the resource to be paid to the server for the information. As an example, the client may display a total amount of orders 500 for the corresponding user, and then the user may send an initial payment amount 200 to the server through the client.

Step 202, determining unpaid resources according to the difference value between the resources to be paid and the initial payment resources.

In this embodiment, the unpaid resource may indicate a resource that is currently left for the resource to be paid and has not yet started to pay. Generally, the unpaid resource can be obtained by calculating the difference between the resource to be paid and the initial payment resource.

In some cases, the initial payment resources or some other factor (e.g., having an associated offer resource, etc.) may affect the unpaid resources. At this time, unpaid resources may be determined in connection with specific application scenarios and application requirements.

As an example, the server receives an initial payment amount 200 of the user order sent by the client for the total amount 500, and then the unpaid resource is 300 (500-.

Step 203, the following payment processing steps 2031-2033 are performed:

step 2031, receive the current payment resource for the unpaid resource, and update the unpaid resource according to the difference between the unpaid resource and the current payment resource.

In this embodiment, after determining the unpaid resource, the server may send information indicating the unpaid resource to the client, and receive the paid resource currently sent by the client for the unpaid resource. The current payment resource may refer to a resource received this time for paying for the current unpaid resource. Typically, the current paid resource is no larger than the current unpaid resource. The unpaid resource may then be updated based on the difference between the unpaid resource and the current paid resource to obtain an updated unpaid resource as the current, up-to-date unpaid resource.

As an example, the unpaid resource is 300, and if the paid resource 100 sent by the client is received later, the unpaid resource may be updated to 200 at this time (300-.

Step 2032, determine if the updated unpaid resource is zero.

In this embodiment, the server may further determine whether the updated unpaid resource is 0 after updating the unpaid resource each time. If the updated unpaid resource is 0, it may indicate that payment for the resource to be paid has been completed. Correspondingly, if the updated unpaid resource is not 0, it may indicate that there still exists a resource that is not paid, that is, payment for the resource to be paid has not been completed.

Step 2033, in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment is successful.

In this embodiment, when the updated unpaid resource is 0, it may be determined that payment for the resource to be paid has been completed, and at this time, the server may return payment result information indicating that payment is successful to the client. For example, a prompt and associated payment credentials are returned to the client with content "payment successful".

In some optional implementations of this embodiment, the payment processing step further includes: and responding to the condition that the updated unpaid resource is not zero, determining the updated unpaid resource as the unpaid resource, and continuing to execute the payment processing steps.

When the updated unpaid resource is not 0, the current unpaid resource can be updated, the updated unpaid resource is used as a new unpaid resource, and the payment processing step is continuously executed until the updated unpaid resource is 0, so that the payment for the resource to be paid is completed.

As an example, the unpaid resource is 300, and then the payment resource 100 sent by the client is received, at this time, the unpaid resource may be updated to 200 (300-. Then, if the payment resource 200 sent by the client is continuously received, the unpaid resource may be updated to 0 (200-.

Alternatively, the current payment resource received from the client at each execution of the payment processing step may be flexibly set by the user of the client. For example, the user of the client may set the payment resource for each transmission according to the actual requirements.

Thus, payment for the resource to be paid can be completed by more than two payments without completing payment for the resource to be paid the next time.

In some optional implementations of this embodiment, the payment method information of the initial payment resource may be different from the payment method information of the current payment resource. The payment method information may be used to indicate a payment method used when the resource is paid. By way of example, where the resource is currency, the payment means include, but are not limited to: credit card payments, savings card payments, third party payment platforms providing various payment means, and the like.

At this time, the information of the payment method of the current payment resource at each execution of the payment processing step may also be different. That is, the payment processing steps are executed in a loop for a plurality of times, and the payment mode of each time can be different.

Alternatively, selectable or available payment methods may be presented at the client to facilitate the user in selecting the payment method he desires to use. The payment mode displayed at the client can be flexibly set according to the actual application scene or application requirements. For example, the user's preference for payment methods may be analyzed according to the user's historical payment records, and then the payment methods with higher user preference may be preferentially shown at the client. For another example, different priorities may be set for different payment methods according to an actual application scenario, and then the different payment methods are displayed on the client according to the sequence of the corresponding priorities from high to low.

Under the condition, when the user completes payment for the resources to be paid through more than two times of payment, different payment modes can be flexibly selected to complete payment every time according to actual application requirements, and the problem that only one payment mode can be used when the payment for the resources to be paid is completed once is solved.

In the prior art, for resources to be paid, a user usually needs a payment process to complete payment of the resources to be paid, and thus, the situation that payment is completed only by using one payment mode and the payment of the resources to be paid is blocked due to quota occurs. For example, after the user selects a payment method, if an excess condition occurs, the user can only quit the current payment page to abandon the payment.

For these situations, the method provided by the above embodiments of the present disclosure may complete payment of the resource to be paid through two or more payment processes, and thus, may provide a user with high flexibility in the payment process, such as controlling the number of payments and the resource paid each time, using different payment methods, and so on. For the user, the method is beneficial to improving the experience of the user in the payment process and reducing the times of payment failure.

With further reference to fig. 3, a flow 300 of yet another embodiment of a payment method is shown. The payment method is applied to a server, and the specific process 300 includes the following steps:

in step 301, a non-single payment request for a resource to be paid is received.

In this embodiment, the non-single payment request may refer to a request to complete payment of the resource to be paid through two or more resource payments. The server can receive a non-single payment request sent by the client. Specifically, the client may be exposed with information indicating a non-single payment request, and a user of the client may then send the non-single payment request to the server according to the information.

As an example, a button for indicating a non-single payment request may be shown in the payment page of the client, and the user may send the non-single payment request to the server by clicking the button.

Step 302, an initial payment resource for a resource to be paid is received based on a non-single payment request.

In this embodiment, after receiving the non-single payment request, an initial payment resource for the resource to be paid may be received in accordance with the non-single payment request. For example, the client may send the initial payment resource at the same time that the non-single payment request is sent.

As an example, a user may use a client to input an initial payment resource and then send a non-single payment request carrying a parameter of the initial payment resource to a server.

Step 303, determining unpaid resources according to the difference between the resources to be paid and the initial payment resources.

Step 304, the following payment processing steps 3041 and 3043 are performed:

step 3041, receiving a current paid resource for the unpaid resource, and updating the unpaid resource according to a difference between the unpaid resource and the current paid resource.

Step 3042, it is determined whether the updated unpaid resource is zero.

Step 3043, in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

In some optional implementations of this embodiment, before step 301, the service end may receive a single payment request for the resource to be paid. Then, in response to determining that the single payment request does not meet the preset payment condition, step 301 of receiving a non-single payment request for the resource to be paid may be further performed.

Wherein, a single payment request may refer to a request to complete payment of the resource to be paid through one resource payment. The server can receive a single payment request sent by the client. In particular, the client may be exposed with information indicating a single payment request, and a user of the client may then send the single payment request to the server according to the information.

After receiving the single payment request, the server may further check the single payment request to determine whether the single payment request meets a preset payment condition. The preset payment condition can be preset according to actual application requirements or application scenes.

As an example, the server may store information indicating whether each client has the authority for single payment in advance. Whether each client has the right to pay a single time may in particular be determined according to the credit of the user of the client. At this time, the server may determine whether the single payment request sent by the client meets the preset payment condition by querying the stored information. Specifically, if the client is queried to have the single payment authority, the single payment request sent by the client may be considered to meet the preset payment condition. Correspondingly, if the client does not have the single payment authority, the single payment request sent by the client can be considered to be not in accordance with the preset payment condition.

Optionally, the server may also receive a single payment resource sent by the client based on the single payment request sent by the client. The single payment resource may refer to a resource for completing payment of the resource to be paid at one time. For example, the client may send a single payment resource at the same time as sending a single payment request.

As an example, the user may use the client to input the single payment resource and then send a single payment request carrying a parameter of the single payment resource to the server.

At this time, the server may determine whether the single payment request meets the preset payment condition by checking the single payment resource corresponding to the single payment request. For example, the server may store condition information indicating a requirement of a single payment resource corresponding to a single payment request for each client in advance, or may determine the condition information indicating the requirement of the single payment resource corresponding to the single payment request for each client in real time.

The server can determine whether the single payment resource corresponding to the single payment request sent by the client meets the preset payment condition or not by inquiring the stored condition information. Specifically, if the single payment resource is found to meet the corresponding condition information, the single payment request sent by the client may be considered to meet the preset payment condition. Correspondingly, if the single payment resource is not in accordance with the corresponding condition information after being inquired, the single payment request sent by the client side can be considered to be not in accordance with the preset payment condition.

The condition information for the single payment resource can be determined according to the actual application scenario. For example, a user's single payment resources may be limited (e.g., the currency of the payment is limited, etc.). As another example, the total payment resources spent by the user for the day are limited.

If the server side determines that the single payment request sent by the client side meets the preset payment condition, the payment of the resource to be paid can be completed according to the single payment resource sent by the client side, and then payment result information used for indicating the successful payment can be returned to the client side.

If the server determines that the single payment request sent by the client does not accord with the preset payment condition, the server may return indication information for indicating that the single payment request sent by the client does not accord with the preset payment condition to the client. Then, the server can receive a non-single payment request sent by the client based on the indication information, and complete payment of the resource to be paid through non-single payment.

The content that is not specifically described in this embodiment may refer to the related description in the corresponding embodiment of fig. 2, and is not repeated herein.

With continued reference to fig. 4, fig. 4 is an exemplary application scenario 400 of the payment method according to the present embodiment. In the application scenario of fig. 4, the amount to be paid 2000 is displayed in the page 4011 of the client 401, and the selectable payment modes include a mode one, a mode two, and a mode three. In addition, a button "non-single payment" is displayed in the page 4011. The user of client 401 may consider the user to select a single payment by default if the user does not click the button. The user may send a single payment request to server 402 requesting that payment of 2000 be completed by means of payment.

When the server 402 determines that the single payment amount of the user is 1500, the excess prompt information indicating the excess of the current payment is returned to the client 401. The user may then click on the button "non-single payment" while modifying the amount to 1000 and send a non-single payment request to server 402 to request a first payment of 1000 using the payment method, as shown in page 4012.

The server 402 may calculate a remaining unpaid amount of 1000 and display it in the client page 4013. The user may further send a non-single payment request to server 402 requesting 1000 a payment first with a payment method.

The server 402 may calculate the remaining unpaid amount to be 0, which indicates that the user has completed payment for the amount to be paid 2000. In turn, the server 402 may return payment details to the user. Specifically, as shown in the client page 4014, the content of the payment details may include information such as "successful payment", "total payment amount 2000", "one payment 1000 by payment method", and "two payment 1000 by payment method".

The method provided by the above embodiment of the present disclosure provides two payment options, namely single payment and non-single payment, to the user, so that the user can select an appropriate payment process according to actual requirements. Meanwhile, the user can complete the payment process through two or more times of payment, so that the problem that the payment is lost due to the conditions such as excess and the like, which often occur in the single payment process, of the user is solved, and the payment efficiency is improved.

With further reference to fig. 5, a flow 500 of yet another embodiment of a payment method is shown. The payment method may be applied to a client (such as

terminal devices

101, 102, 103, etc. shown in fig. 1). The process 500 of the payment method specifically includes the following steps:

step 501, an initial payment resource for a resource to be paid is sent.

In this embodiment, the executing entity of the payment method (such as the

terminal devices

101, 102, 103, etc. shown in fig. 1) may send the initial payment resource to the server (such as the server, etc. shown in fig. 1). Specifically, the client may display information indicating the resource to be paid, and send the initial payment resource for the resource to be paid to the server for the information. Typically, the initial payment resource is smaller than the resource to be paid.

Step 502, receive unpaid resources.

In this embodiment, the unpaid resource may be determined according to a difference between the resource to be paid and the initial payment resource. Generally, the unpaid resource can be obtained by the server by calculating the difference between the resource to be paid and the initial payment resource.

Step 503, the following

payment steps

5031 and 5032 are executed:

step 5031, sending the current payment resource for the unpaid resource.

In this embodiment, the client may send the payment resource to the server as the current payment resource for the current unpaid resource. Typically, the current paid resource is no larger than the current unpaid resource. Then, the server side can update the unpaid resources according to the difference value between the unpaid resources and the current payment resources, so that the updated unpaid resources are obtained and serve as the current latest unpaid resources, and the latest unpaid resources are sent to the client side.

In addition, the server may further determine whether the updated unpaid resource is 0 after updating the unpaid resource each time. If the updated unpaid resource is 0, it may indicate that payment for the resource to be paid has been completed. Correspondingly, if the updated unpaid resource is not 0, it may indicate that there are still resources that have not been paid, that is, payment for the resource to be paid has not been completed.

Step 5032, receiving payment result information indicating that the payment is successful.

In this embodiment, the payment result information may be sent by the server to the client in response to determining that the updated unpaid resource is zero. The updated unpaid resource can be determined by the service terminal according to the difference value between the unpaid resource and the current payment resource.

When the updated unpaid resource is 0, it may indicate that payment for the resource to be paid has been completed, and at this time, the client may receive payment result information that is returned by the server and used for indicating that payment is successful.

Optionally, the current payment resource sent by the client to the server in each execution of the payment step may be flexibly set. For example, the payment resource for each transmission may be set by the user according to actual requirements.

In some optional implementations of the embodiment, in response to determining that the updated non-paid resource is not zero, the payment step continues as described above. When the updated unpaid resource is not 0, the server updates the current unpaid resource, uses the updated unpaid resource as a new unpaid resource, and returns the new unpaid resource to the client. The client can then continue to send the payment resource for the current unpaid resource until receiving payment result information returned by the server and indicating that the payment is successful when the updated unpaid resource is 0.

At this time, the payment method information of the current payment resource at each execution of the payment step may also be different. That is, the payment procedure may be executed multiple times in a loop, and the payment method may be different for each time.

Optionally, the client may present payment methods that are selectable or available to the user to facilitate the user in selecting the payment method they desire to use. The payment mode displayed by the client can be flexibly set according to the actual application scene or application requirements. For example, the preference of the user for the payment mode can be analyzed according to the historical payment record of the user, and the payment mode with higher preference degree of the user is preferentially displayed at the client. For another example, different priorities may be set for different payment methods according to an actual application scenario, and then the different payment methods are presented at the client according to a sequence from high to low of the corresponding priorities.

In some optional implementation manners of this embodiment, the client may further send a non-single payment request for the resource to be paid to the server, and then send the initial payment resource for the resource to be paid to the server based on the non-single payment request. The above steps 502-503 may be continued to complete the payment of the resource to be paid.

Specifically, the client may be exposed with information indicating a non-single payment request, and then a user of the client may send the non-single payment request to the server according to the information. As an example, a button for indicating a non-single payment request may be shown in the payment page of the client, and the user may send the non-single payment request to the server by clicking the button.

Alternatively, the client may send the initial payment resource at the same time as sending the non-single payment request to the server. As an example, a user may use a client to input an initial payment resource and then send a non-single payment request carrying a parameter of the initial payment resource to a server.

In some optional implementations of this embodiment, before step 501, the client may send a single payment request for the resource to be paid to the server. Then, in response to determining that the single payment request does not meet the preset payment condition, the client may further perform step 502 described above to send a non-single payment request for the resource to be paid to the server.

In particular, the client may be exposed with information indicating a single payment request, and a user of the client may then send the single payment request to the server according to the information. After receiving the single payment request, the server may further verify the single payment request to determine whether the single payment request meets the preset payment condition, and return information indicating whether the single payment request meets the preset payment condition to the client. The client can determine whether the single payment request meets the preset payment condition according to the information which is returned by the server and used for indicating whether the single payment request meets the preset payment condition.

The preset payment condition can be preset according to actual application requirements or application scenes.

Optionally, the client may also send the single payment resource to the server based on the single payment request sent by the client. The single payment resource may refer to a resource for completing payment of the resource to be paid at one time. For example, the client may send a single payment resource at the same time as sending a single payment request. As an example, the user may use the client to input the single payment resource and then send a single payment request carrying a parameter of the single payment resource to the server.

At this time, the server may determine whether the single payment request meets the preset payment condition by checking the single payment resource corresponding to the single payment request. Specifically, if the single payment resource is found to meet the corresponding condition information, the single payment request sent by the client may be considered to meet the preset payment condition. Correspondingly, if the single payment resource is not in accordance with the corresponding condition information, the single payment request sent by the client can be considered to be not in accordance with the preset payment condition.

If the single payment request sent by the client side meets the preset payment condition, the payment of the resource to be paid can be completed by using the single payment request, and payment result information which is returned by the server side and used for indicating the successful payment is received.

If the single payment request sent by the client does not meet the preset payment condition, a non-single payment request can be sent to the server to request that payment of the resource to be paid is completed through non-single payment.

The content that is not specifically described in this embodiment may refer to the related description in the embodiment corresponding to fig. 2 to fig. 3, and is not repeated herein.

The method provided by the above embodiment of the present disclosure can complete payment of the resource to be paid through two or more payment processes, and thus, can provide higher flexibility for the user in the payment process, such as controlling the number of payments and the resource paid each time, using different payment methods, and the like. For the user, the method is helpful for improving the experience of the user in the payment process and reducing the number of payment failures.

With further reference to fig. 6, a timing diagram 600 of one embodiment of a payment system is shown. The payment system includes a client (such as

terminal devices

101, 102, 103, etc. shown in fig. 1) and a server (such as server 105, etc. shown in fig. 1).

In step 601, the client sends an initial payment resource for the resource to be paid to the server.

In step 602, the server determines unpaid resources according to a difference between the resources to be paid and the initial payment resources.

In step 603, the server sends the unpaid resource to the client.

In step 604, the client sends the current payment resource for the unpaid resource to the server.

In step 605, the server updates the unpaid resource according to the difference between the unpaid resource and the current payment resource, and determines whether the updated unpaid resource is zero.

In step 606, the server returns payment result information indicating that the payment is successful to the client in response to determining that the updated unpaid resource is zero.

Optionally, in response to determining that the updated unpaid resource is not zero, the server may determine the updated unpaid resource as an unpaid resource, and continue to execute the above step 603 and 606.

Optionally, the client may also send a non-single payment request for the resource to be paid to the server; and then sending the initial payment resource aiming at the resource to be paid to the server according to the non-single payment request. Step 602 and step 606 may be performed thereafter.

Optionally, the client may also send a single payment request for the resource to be paid to the server; and then the server side can check whether the single payment request meets the preset payment condition. The server side can send information used for indicating that the single payment request does not accord with the preset payment condition to the server side in response to the fact that the single payment request does not accord with the preset payment condition. Then, the client side can send a non-single payment request aiming at the resource to be paid to the server side according to the information used for indicating that the single payment request does not accord with the preset payment condition.

Alternatively, the payment means information of the initial payment resource may be different from the payment means information of the current payment resource. In addition, the payment mode information of the current payment resource sent to the server by the client at each time can be different.

Optionally, the server may be configured according to actual application requirements and application scenarios. For example, the service end may include a first service end and a second service end. The first service end can perform direct information interaction with the client. The second server may interact with the first server to process information received by the first server from the client to generate information for sending to the client.

As an example, the first server may be configured to receive a single payment request sent by the client, receive a single payment resource sent by the client, and verify whether the single payment request meets a preset payment condition according to the single payment resource; if the single payment resource check shows that the single payment request does not accord with the preset payment condition, the first server side can send payment result information used for indicating payment failure to the client side; if the single payment resource verifies that the single payment request meets the preset payment condition, the first service terminal can complete the payment process for the resource to be paid and send payment result information used for indicating successful payment to the client terminal.

The first server can also be used for receiving a non-single payment request sent by the client, receiving initial payment resources sent by the client and sending the initial payment resources to the second server. The second server may be configured to determine the unpaid resource according to a difference between the initial payment resource and the resource to be paid, and determine whether the unpaid resource is 0; if the unpaid resource is 0, the second service end can inform the first service end of sending payment result information for indicating successful payment to the client; if the unpaid resource is not 0, the second service end can inform the first service end to continue to receive the current payment resource sent by the client end and continue to update the unpaid resource so as to complete the payment process of the resource to be paid.

The content that is not specifically described in this embodiment may refer to the related description in the embodiment corresponding to fig. 2 to fig. 5, and is not repeated herein.

According to the payment system provided by the embodiment of the disclosure, the client sends the initial payment resource aiming at the resource to be paid to the server, the server determines the unpaid resource according to the initial payment resource, receives the current payment resource sent by the client, updates the unpaid resource according to the current payment resource, and determines that the payment is successful until the updated unpaid resource is zero. Therefore, the payment process of the resource to be paid can be completed through two or more payments, so that a new payment process is added, and meanwhile, the flexibility of the payment process can be improved.

With further reference to fig. 7, as an implementation of the method shown in fig. 2, the present disclosure provides an embodiment of a payment apparatus applied to a server, where the apparatus embodiment corresponds to the method embodiment shown in fig. 2, and the apparatus may be applied to various electronic devices.

As shown in fig. 7, the payment apparatus 700 provided in the present embodiment includes an initial payment resource receiving unit 701, a determining unit 702, and a payment processing unit 703. Wherein the initial payment resource receiving unit 701 is configured to receive an initial payment resource for a resource to be paid; the determining unit 702 is configured to determine the unpaid resource based on a difference between the resource to be paid and the initial payment resource; the payment processing unit 703 is configured to perform the following payment processing steps: receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

In the present embodiment, in the payment apparatus 700: the specific processing of the initial payment resource receiving unit 701, the determining unit 702, and the payment processing unit 703 and the technical effects thereof may refer to the related descriptions of step 201, step 202, and step 203 in the corresponding embodiment of fig. 2, which are not described herein again.

In some optional implementations of the present embodiment, the payment apparatus 700 further includes: a non-single payment request receiving unit (not shown in the figure) configured to receive a non-single payment request for the resource to be paid; the initial payment resource receiving unit 701 is further configured to receive an initial payment resource for the resource to be paid based on the non-single payment request.

In some optional implementations of the present embodiment, the payment apparatus 700 further includes: a single payment request receiving unit (not shown in the figure) configured to receive a single payment request for the resource to be paid; the above non-single payment request receiving unit is further configured to receive a non-single payment request for the resource to be paid in response to determining that the single payment request does not comply with the preset payment condition.

In some optional implementation manners of this embodiment, the payment manner information of the initial payment resource is different from the payment manner information of the current payment resource; and the payment processing steps are different in payment mode information of the current payment resources in each execution.

The payment device provided by the above embodiment of the present disclosure receives an initial payment resource for a resource to be paid through an initial payment resource receiving unit; the determining unit determines unpaid resources according to the difference value between the resources to be paid and the resources to be paid initially; the payment processing unit performs the following payment processing steps: receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful. Therefore, two payment options of single payment and non-single payment can be provided for the user, so that the user can conveniently select a proper payment process according to actual requirements. Meanwhile, the user can complete the payment process through two or more times of payment, so that the problem that the payment fails due to the conditions such as excess and the like which often occur in the single payment process of the user is solved, and the payment efficiency is improved.

With further reference to fig. 8, as an implementation of the method shown in fig. 5, the present disclosure provides yet another embodiment of a payment apparatus applied to a client, where the apparatus embodiment corresponds to the method embodiment shown in fig. 5, and the apparatus may be applied to various electronic devices.

As shown in fig. 8, the payment apparatus 800 provided by the present embodiment includes an initial payment resource transmitting unit 801, an unreceived resource receiving unit 802, and a payment unit 803. The initial payment resource transmitting unit 801 is configured to transmit an initial payment resource for a resource to be paid; the unpaid resource receiving unit 802 is configured to receive unpaid resources, wherein the unpaid resources are determined according to a difference value between the resource to be paid and the initial payment resource; the payment unit 803 is configured to perform the following payment steps: sending a current payment resource for the unpaid resource; receiving payment result information indicating that payment is successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, the updated unpaid resource being determined based on a difference between the unpaid resource and the current payment resource.

In the present embodiment, in the payment apparatus 800: the specific processing of the initial payment resource sending unit 801, the unreceived resource receiving unit 802, and the payment unit 803, and the technical effects thereof can refer to the related descriptions of step 501, step 502, and step 503 in the embodiment corresponding to fig. 5, which are not described herein again.

In some optional implementations of this embodiment, the payment step further includes: and responding to the non-payment resource after the updating is determined not to be zero, and continuing to execute the payment step.

In some optional implementations of this embodiment, the payment apparatus 800 further includes: a non-single payment request transmitting unit (not shown in the figure) configured to transmit a non-single payment request for a resource to be paid; and the initial payment resource sending unit 801 is further configured to send an initial payment resource for the resource to be paid based on the non-single payment request.

In some optional implementations of this embodiment, the payment apparatus 800 further includes: a single payment request transmitting unit (not shown in the figure) configured to transmit a single payment request for a resource to be paid; the non-single payment request sending unit is further configured to: in response to determining that the single payment request does not comply with the preset payment condition, sending a non-single payment request for the resource to be paid.

In some optional implementation manners of this embodiment, the payment manner information of the initial payment resource is different from the payment manner information of the current payment resource; and the payment mode information of the current payment resource in each execution of the payment step is different.

The payment device provided by the above embodiment of the present disclosure transmits the initial payment resource for the resource to be paid through the initial payment resource transmitting unit; the method comprises the steps that an unpaid resource receiving unit receives unpaid resources, wherein the unpaid resources are determined according to the difference value of resources to be paid and initial payment resources; the payment unit performs the following payment steps: sending a current payment resource for the unpaid resource; receiving payment result information indicating that the payment was successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, the updated unpaid resource being determined from a difference between the unpaid resource and the current payment resource. Therefore, the user can be provided with higher flexibility in the payment process, such as controlling the payment times and the resource of each payment, using different payment methods and the like. For the user, the method is beneficial to improving the experience of the user in the payment process and reducing the number of times of payment failure.

Referring now to FIG. 9, a schematic diagram of an electronic device (e.g., the server of FIG. 1) 900 suitable for use in implementing embodiments of the present disclosure is shown. The electronic device shown in fig. 9 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 9, the electronic device 900 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 901 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)902 or a program loaded from a storage device 908 into a Random Access Memory (RAM) 903. In the RAM 903, various programs and data necessary for the operation of the electronic apparatus 900 are also stored. The processing apparatus 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An input/output (I/O) interface 905 is also connected to bus 904.

Generally, the following devices may be connected to the I/O interface 905: input devices 906 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; an output device 907 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 908 including, for example, magnetic tape, hard disk, etc.; and a communication device 909. The communication means 909 may allow the electronic device 900 to communicate with other devices wirelessly or by wire to exchange data. While fig. 9 illustrates an electronic device 900 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in fig. 9 may represent one device or may represent a plurality of devices as desired.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program containing program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication device 909, or installed from the storage device 908, or installed from the ROM 902. The computer program, when executed by the processing device 901, performs the above-described functions defined in the methods of the embodiments of the present disclosure.

It should be noted that the computer readable medium described in the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In embodiments of the disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In embodiments of the present disclosure, however, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: receiving an initial payment resource for a resource to be paid; determining unpaid resources according to the difference value between the resources to be paid and the initial payment resources; the following payment processing steps are performed: receiving current payment resources for unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present disclosure may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes an initial payment resource receiving unit, a determining unit, and a payment processing unit. Here, the names of these units do not constitute a limitation to the unit itself in some cases, and for example, the initial payment resource receiving unit may also be described as a "unit that receives initial payment resources for resources to be paid".

The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above-mentioned features, but also covers other embodiments formed by any combination of the above-mentioned features or their equivalents without departing from the inventive concept. For example, the technical solutions formed by mutually replacing the above-mentioned features with (but not limited to) technical features having similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A payment method is applied to a server and comprises the following steps:

receiving an initial payment resource for a resource to be paid;

determining unpaid resources according to the difference value between the resources to be paid and the initial payment resources;

the following payment processing steps are performed:

receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources;

determining whether the updated unpaid resource is zero;

in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

2. The method of claim 1, wherein the payment processing step further comprises:

and in response to determining that the updated unpaid resources are not zero, determining the updated unpaid resources as unpaid resources, and continuing to execute the payment processing step.

3. The method of claim 1, wherein the method further comprises:

receiving a non-single payment request for the resource to be paid; and

the receiving an initial payment resource for a resource to be paid comprises:

receiving an initial payment resource for a resource to be paid based on the non-single payment request.

4. The method of claim 3, wherein the method further comprises:

receiving a single payment request for the resource to be paid; and

the receiving a non-single payment request for the resource to be paid comprises:

receiving a non-single payment request for the resource to be paid in response to determining that the single payment request does not comply with a preset payment condition.

5. The method according to one of claims 1 to 4, wherein the payment means information of the initial payment resource is different from the payment means information of the current payment resource; and

the payment processing step is different in payment mode information of the current payment resource in each execution.

6. A payment method is applied to a client and comprises the following steps:

sending an initial payment resource for the resource to be paid;

receiving unpaid resources, wherein the unpaid resources are determined according to the difference value between the resources to be paid and the initial payment resources;

the following payment steps are performed:

sending a current payment resource for the unpaid resource;

receiving payment result information indicating that payment is successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, and the updated unpaid resource is determined according to a difference between the unpaid resource and the current payment resource.

7. The method of claim 6, wherein the payment step further comprises:

in response to determining that the updated unpaid resources are not zero, continuing to perform the payment step.

8. The method of claim 6, wherein the method further comprises:

sending a non-single payment request for the resource to be paid; and

the sending of the initial payment resource for the resource to be paid comprises:

based on the non-single payment request, an initial payment resource for the resource to be paid is sent.

9. The method of claim 8, wherein the method further comprises:

sending a single payment request for the resource to be paid; and

the sending a non-single payment request for the resource to be paid comprises:

sending a non-single payment request for the resource to be paid in response to determining that the single payment request does not meet a preset payment condition.

10. The method according to one of claims 6 to 9, wherein the payment means information of the initial payment resource is different from the payment means information of the current payment resource; and

the payment step is carried out in each time, the payment mode information of the current payment resource is different.

11. A payment system comprises a client and a server;

the server for executing the method of any one of claims 1-5;

the client for performing the method of any one of claims 6-10.

12. A payment device is applied to a server and comprises:

an initial payment resource receiving unit configured to receive an initial payment resource for a resource to be paid;

a determining unit configured to determine unpaid resources according to a difference value between the resources to be paid and initial payment resources;

a payment processing unit configured to perform the following payment processing steps: receiving current payment resources aiming at the unpaid resources, and updating the unpaid resources according to the difference value of the unpaid resources and the current payment resources; determining whether the updated unpaid resource is zero; in response to determining that the updated unpaid resource is zero, returning payment result information indicating that the payment was successful.

13. A payment device applied to a client comprises:

an initial payment resource transmitting unit configured to transmit an initial payment resource for a resource to be paid;

an unpaid resource receiving unit configured to receive unpaid resources, wherein the unpaid resources are determined according to a difference value between the resources to be paid and initial payment resources;

a payment unit configured to perform the following payment steps: sending a current payment resource for the unpaid resource; receiving payment result information indicating that payment is successful, wherein the payment result information is sent in response to determining that the updated unpaid resource is zero, and the updated unpaid resource is determined according to a difference between the unpaid resource and the current payment resource.

14. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon;

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-10.

15. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-10.