CN109118213B

CN109118213B - Online payment method, device, terminal and storage medium

Info

Publication number: CN109118213B
Application number: CN201810904090.5A
Authority: CN
Inventors: 张明远
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-08-09
Filing date: 2018-08-09
Publication date: 2022-08-05
Anticipated expiration: 2038-08-09
Also published as: CN109118213A

Abstract

The invention provides an online payment method, an online payment device, a terminal and a storage medium. The method is applied to a payer client, and comprises the following steps: receiving a payment token message sent by a server, wherein the payment token message carries a payment token and a use condition of the payment token, and the use condition refers to a condition required to be met by adopting the payment token to complete a payment process; when the mobile terminal is in a payment scene, detecting whether the payment scene meets the use condition; and if the payment scene meets the use condition, completing the payment process through the resources in the payment token. In the invention, the payment token is obtained from the client of the payment assistant in advance before the payment process is completed, and then when the client of the payment assistant is in a payment scene, the payment process can be completed through the resources in the payment token, thereby avoiding the condition that the client of the payment assistant needs to confirm the client of the payment assistant on line when requesting the payment assistant, and improving the success rate and the efficiency of the on-line payment.

Description

Online payment method, device, terminal and storage medium

Technical Field

The embodiment of the invention relates to the technical field of computers and internet, in particular to an online payment method, an online payment device, a terminal and a storage medium.

Background

Currently, some applications with online transaction functionality provide a payment-for-payment functionality. That is, the payment process is completed by the borrower being replaced by the amount in the virtual account of the lender.

In the related art, a "finding person for payment instead" option is provided in a payment interface displayed by a borrowing terminal, after a user selects the option, the borrowing terminal displays a contact list, the user selects a payment substitute contact in the contact list, then the borrowing terminal sends a payment substitute request to a payment substitute terminal used by the payment substitute contact, the payment substitute terminal displays a corresponding payment substitute interface after receiving the payment substitute request, and the payment substitute terminal receives payment verification information (such as a password and a fingerprint) of the payment substitute contact input in the payment substitute interface, completes a payment substitute process and sends a payment substitute completion notification to the borrowing terminal.

In the related art, when the contact person making a payment fails to input the payment verification information in time due to offline or other situations, the failure of making a payment is caused.

Disclosure of Invention

The embodiment of the invention provides an online payment method, an online payment device and a terminal storage medium, which can be used for solving the problem of failure of the current payment contact in the related art when payment verification information is not timely input due to offline or other conditions.

In one aspect, an embodiment of the present invention provides a payment-on-behalf method, which is applied to a client of a payer, and the method includes:

receiving a payment token message sent by a server, wherein the payment token message carries a payment token and a use condition of the payment token, the use condition refers to a condition which needs to be met when the payment token is adopted to complete a payment process, and the use condition comprises at least one of an available consumption amount, an available consumption type, available payment time and available payment times;

when the mobile terminal is in a payment scene, detecting whether the payment scene meets the use condition;

and if the payment scene meets the use condition, completing the payment process through the resources in the payment token.

On the other hand, the embodiment of the invention provides an online payment method, which is applied to a client of a payment agent, and the method comprises the following steps:

when a payment token generation instruction is acquired, displaying a payment token setting interface;

receiving payment token parameters and use conditions input in the payment token setting interface, wherein the use conditions refer to conditions required to be met by completing a payment process by adopting a payment token, and the use conditions comprise at least one of available consumption amount, available consumption type, available payment time and available payment times;

sending a payment token generation request to a server, wherein the payment token generation request carries the payment token parameters and the use conditions; the server is used for generating the payment token according to the payment token generation request, sending a payment token message to a payer client indicated by the payment token parameters, wherein the payment token message carries the payment token and the use condition, the payer client is used for detecting whether the payment scene meets the use condition or not when the payer client is in the payment scene, and if the payment scene meets the use condition, completing a payment process through resources in the payment token.

In another aspect, an embodiment of the present invention provides an online payment apparatus, which is applied to a payer client, where the apparatus includes:

the message receiving module is used for receiving a payment token message sent by a server, wherein the payment token message carries a payment token and a use condition of the payment token, the use condition refers to a condition which needs to be met when the payment token is adopted to complete a payment process, and the use condition comprises at least one of available consumption amount, available consumption type, available payment time and available payment times;

the condition detection module is used for detecting whether the payment scene meets the use condition or not when the payment scene is in the payment scene;

and the payment module is used for completing the payment process through the resources in the payment token if the payment scene meets the use condition.

In another aspect, an embodiment of the present invention provides an online payment apparatus, which is applied to a client of a payer, where the apparatus includes:

the interface display module is used for displaying a payment token setting interface when a payment token generation instruction is acquired;

the payment token setting interface is used for receiving payment token parameters and use conditions input in the payment token setting interface, wherein the use conditions refer to conditions required to be met by a payment token to complete a payment process, and the use conditions comprise at least one of available consumption amount, available consumption type, available payment time and available payment times;

the request sending module is used for sending a payment token generation request to a server, wherein the payment token generation request carries the payment token parameters and the use conditions; the server is used for generating the payment token according to the payment token generation request, sending a payment token message to a payer client indicated by the payment token parameters, wherein the payment token message carries the payment token and the use condition, the payer client is used for detecting whether the payment scene meets the use condition or not when the payer client is in the payment scene, and if the payment scene meets the use condition, completing a payment process through resources in the payment token.

In yet another aspect, an embodiment of the present invention provides a terminal, which includes a processor and a memory, where the memory stores at least one instruction, at least one program, a code set, or a set of instructions, and the at least one instruction, the at least one program, the code set, or the set of instructions is loaded and executed by the processor to implement the online payment method according to the above aspect.

In yet another aspect, an embodiment of the present invention provides a terminal, which includes a processor and a memory, where the memory stores at least one instruction, at least one program, a code set, or a set of instructions, and the at least one instruction, the at least one program, the code set, or the set of instructions is loaded and executed by the processor to implement the online payment method according to the above another aspect.

In yet another aspect, an embodiment of the present invention provides a computer-readable storage medium having at least one instruction, at least one program, a set of codes, or a set of instructions stored therein, which is loaded and executed by a processor to implement the online payment method according to the above-mentioned aspect.

In yet another aspect, embodiments of the present invention provide a computer-readable storage medium having at least one instruction, at least one program, a set of codes, or a set of instructions stored therein, which is loaded and executed by a processor to implement the online payment method according to the above another aspect.

In yet another aspect, a computer program product is provided for performing the online payment method of one aspect described above when executed.

In yet another aspect, a computer program product is provided for performing the online payment method of the above another aspect when the computer program product is executed.

The technical scheme provided by the embodiment of the invention can bring the following beneficial effects:

the payment token is obtained from the client of the payment assistant in advance before the payment process is completed, and then when the client of the payment assistant is in a payment scene, the payment process can be completed through the resources in the payment token, so that the condition that the client of the payment assistant needs to confirm the client of the payment assistant on line when the client of the payment assistant requests the payment assistant is avoided, and the success rate and the efficiency of the payment can be improved.

Drawings

FIG. 1 is a schematic diagram of an implementation environment shown in one embodiment of the present invention;

FIG. 2 is a flow diagram illustrating an online payment method according to one embodiment of the invention;

FIG. 3 is a schematic diagram of an interface for a payment token, shown in one embodiment of the present invention;

FIG. 4 is a block diagram illustrating an online payment method, according to one embodiment of the invention;

FIG. 5 is a flow diagram illustrating a method of online payment according to another embodiment of the invention;

FIG. 6 is a schematic diagram of an interface for setting up a payment token, according to one embodiment of the invention;

FIG. 7 is a schematic diagram of an interface for setting up a payment token, according to another embodiment of the invention;

FIG. 8 is a flow diagram illustrating a method of online payment according to another embodiment of the invention;

FIG. 9 is a block diagram of an online payment device shown in one embodiment of the present invention;

FIG. 10 is a block diagram of an online payment device shown in another embodiment of the present invention;

FIG. 11 is a block diagram of an online payment device shown in another embodiment of the present invention;

fig. 12 is a block diagram illustrating a terminal according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Before describing the embodiments of the present invention, the related terms related to the embodiments of the present invention will be described.

Resource: refers to the virtual items required to complete the payment process, which may be currency, game coins, credits, shoe-shaped gold ingots, gold beans, gift certificates, redemption coupons, etc. In embodiments of the invention, it is carried in a payment token.

Available consumption type: one usage condition of the payment token refers to a consumption type allowing the payment process to be completed through the resources in the payment token, which can be set by the payment-on-behalf user.

Available consumption limit: one condition of use of a payment token refers to the amount of resources carried in the payment token.

Available payment time: one condition of use of the payment token refers to the time allowed for completing the payment process through the resource in the payment token, which can be set by the payment agent user.

Number of available payments: one condition of use of the payment token refers to the number of times that the payment process is allowed to be completed by the resource in the payment token, which can be set by the payment agent user.

Special credit associated with consumption type: the amount of the resource allowed to be used when the payment process corresponding to the consumption type is completed is referred to. When the use condition of the payment token comprises the available consumption type and the available consumption amount, the payment-substituting user can set special amount for different consumption types, and the special amount related to different consumption types can be the same or different. In addition, the sum of the special limit respectively associated with each consumption type can be smaller than or equal to the available consumption limit.

Referring to fig. 1, a schematic diagram of an implementation environment is shown according to an embodiment of the invention. The implementation environment includes:

a payment terminal 120, a server 140, and a payment terminal 160.

The payment assistant terminal 120 runs a payment assistant client. Optionally, the client of the payer has a function of sending the payment token. The payment terminal 120 may be a mobile phone, a tablet computer, an e-book reader, an MP3(Moving Picture Experts Group Audio Layer III, mpeg compression standard Audio Layer 3) player, an MP4(Moving Picture Experts Group Audio Layer IV, mpeg compression standard Audio Layer 4) player, a laptop computer, a desktop computer, or the like.

The server 140 may be a server, a server cluster composed of several servers, or a cloud computing service center. The server 140 may be a backend server corresponding to the payer client and the payer client.

Alternatively, when the server 140 is a server cluster consisting of several servers, the server 140 includes a background server, a payment server. The background server is used for realizing the transmission of messages between the client of the payer and the client of the payer; the payment server is used for realizing a payment function, for example, transferring resources in an account corresponding to the payer client to a payee account. Optionally, the server 140 further includes a third-party server, and the third-party server may be a background server corresponding to the shopping client.

The payer terminal 160 has a payer client running therein. Optionally, the payer client has a receiving function of the payment token and an online payment function. The payment terminal 160 may also be a cell phone, a tablet, an e-book reader, an MP3 player, an MP4 player, a laptop portable computer, a desktop computer, etc.

The server 140 may establish communication connections with the escrow terminal 120 and the payment terminal 160, respectively, through a network. The network may be a wireless network or a wired network.

In the embodiment of the invention, the client of the payment assistant and the client of the payer can be any client with the functions of sending and receiving the payment token. For example, the payer client may be a social-type application client, an instant messaging client, a payment-type application client, a game client, a reading client, a client dedicated to sending payment tokens, and so forth.

In practical applications, the client of the payer and the client of the payer can be two clients with different functions, wherein the client of the payer has the function of sending the payment token, and the client of the payer has the function of receiving the payment token. Alternatively, the payer client and the payer client may be two clients having the same function, and the clients have a function of transmitting and receiving the payment token. When the client is used for realizing the functions of the client side of the payment agent in the method example of the invention, the client is used as the client side of the payment agent; when the client is used to implement the functions of the client side of the payer in the example of the method of the present invention, the client is the client of the payer. Correspondingly, the payment terminal and the payment terminal are both terminal equipment. When the client running in the terminal device is used for realizing the function of the client side of the payment agent in the method example of the invention, the terminal device is used as the payment agent terminal; when the client running in the terminal device is used for realizing the functions of the client side of the payer in the method example of the invention, the terminal device is used as the payment terminal. In practical application, the same client can be used as a client of a payment agent and a client of a payment party. The same terminal can be used as a payment terminal or a payment terminal.

Referring to fig. 2, a flow chart of an online payment method according to an embodiment of the invention is shown. The method is applied to a payer client and comprises the following steps.

Step 201, receiving a payment token message sent by a server.

The payment token message carries the payment token and the usage conditions of the payment token. A payment token is a virtual carrier that transfers resources in a complimentary fashion between at least two users. The at least two users have a friend relationship, or may not have a friend relationship, in the client and/or the real world. The use condition of the payment token refers to a condition which needs to be satisfied to complete a payment process by using the payment token.

The payment token carries the resource, and for the explanation of the resource, reference may be made to the related noun, which is not described herein again. Optionally, the payment token further includes an identification of the client of the payer who sent the payment token.

Optionally, the usage condition includes at least one of an available consumption amount, an available consumption type, an available payment time, and an available payment number. In a possible implementation manner, the usage condition includes an available consumption type, and further includes at least one of an available consumption amount, an available payment time and an available payment number.

The amount of resources carried in the token may be paid for by the spending limit. It should be noted that the available credit is not a constant, but may be updated based on the initial credit and the used credit for completing the payment process by the resource in the payment token. The initial consumption limit is set by the user of the payment agent in a self-defined way.

The available consumption type refers to a consumption type that allows the payment process to be completed through the resource in the payment token, which can be customized by the payment user. The available consumption type is set by the payment-substituting user, and may include stationery, books, food, living goods, and the like, which is not limited by the embodiment of the present invention. The available payment time refers to the time allowed for completion of the payment process by the resource in the payment token, which may be set by the payment-on-behalf user. The number of available payments refers to the number of times the payment process is allowed to complete by the resource in the payment token, which may also be set by the payment-on-behalf user.

Referring collectively to fig. 3, there is shown a schematic interface diagram of a payment token 31, shown in one embodiment of the invention. The payment token 31 includes an identification 311 "user B", an available consumption amount 312 "300 yuan", an available consumption number 313 "5", an available consumption type 314 "book, stationery, food", and an available payment time 315 "2018.07.26-2018.08.01" of the client of the payer who sent the payment token 31.

In addition, when the using condition comprises the available consumption amount and the available consumption type, the available consumption type comprises n consumption types, the available consumption amount comprises a special amount respectively associated with the n consumption types, and n is an integer larger than 1. The special quota associated with the consumption type refers to the amount of resources allowed to be used when the payment process corresponding to the consumption type is completed. When the use condition of the payment token comprises the available consumption type and the available consumption amount, the payment-substituting user can set special amount for different consumption types, and the special amount related to different consumption types can be the same or different. In addition, the sum of the special limit respectively associated with each consumption type can be smaller than or equal to the available consumption limit. With reference to Table-1, there is illustrated n consumption types, and the respective associated private lines for the n consumption types.

TABLE-1

Type of consumption	Consumption type associated special quota
		Daily products	1000
Food products	2000
		Stationery and book	1000

Optionally, after receiving the payment token message, the payer client may also display the payment token message for viewing by the payer user. The embodiment of the present invention does not limit the interface for displaying the payment token message. In one example, the payer client displays the payment token message on a single chat session interface with the payer client that sent the payment token. In another example, the payer client displays the payment token message on a notification interface.

Step 202, when the payment scene is in the payment scene, detecting whether the payment scene meets the use condition.

A payment scenario refers to a scenario in which an item or a service needs to be acquired through resource exchange.

When the usage conditions include available spending limits, step 202 may be implemented as: detecting whether the quantity of resources required by the payment scene is larger than the available consumption amount. If the quantity of the resources required by the payment scene is not greater than the available consumption limit, determining that the payment scene meets the use condition; and if the quantity of the resources required by the payment scene is greater than the available consumption limit, determining that the payment scene does not meet the use condition, and ending the process.

When the usage conditions include available spending amounts, step 202 may be implemented as: and detecting whether the consumption type corresponding to the payment scene belongs to the available consumption type. If the consumption type corresponding to the payment scene belongs to the available consumption type, determining that the payment scene meets the use condition; and if the consumption type corresponding to the payment scene does not belong to the available consumption type, determining that the payment scene does not meet the use condition, and ending the process.

Optionally, the payer client searches whether a consumption type corresponding to the payment scene exists in the available consumption types, and if the consumption type corresponding to the payment scene exists in the available consumption types, determines that the consumption type corresponding to the payment scene belongs to the available consumption type; and if the consumption type corresponding to the payment scene does not exist in the available consumption types, determining that the consumption type corresponding to the payment scene does not belong to the available consumption type.

When the usage conditions include an available payment time, step 202 may be implemented as: and detecting whether the payment time corresponding to the payment scene is in the available payment time. If the payment time corresponding to the payment scene is in the available payment time, determining that the payment scene meets the use condition; and if the payment time corresponding to the payment scene is not in the available payment time, determining that the payment scene does not meet the use condition, and ending the process.

When the usage conditions include the number of available payments, step 202 may be implemented as: and detecting whether the payment times corresponding to the payment scene are larger than the available payment times. If the payment times corresponding to the payment scene are not more than the available payment times, determining that the payment scene meets the use condition; and if the payment times corresponding to the payment scene are larger than the available payment times, determining that the payment scene does not meet the use condition, and ending the process.

In addition, when the usage condition includes a plurality of items of available consumption amount, available consumption type, available payment time, and available payment times, the payer client does not have a limitation on the detection order of detecting whether the payment scenario satisfies the usage condition.

Alternatively, when the usage condition includes an available consumption amount and an available consumption type, the available consumption type includes n consumption types, and the available consumption amount includes a dedicated amount associated with each of the n consumption types, step 202 may include the following sub-steps:

step 202a, detecting whether the consumption type corresponding to the payment scene belongs to an available consumption type;

if the consumption type corresponding to the payment scene belongs to the available consumption type, continuing to execute the step 202b and the step 202c, if the consumption type corresponding to the payment scene does not belong to the available consumption type, determining that the payment scene does not meet the use condition, and ending the process.

Step 202b, if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a target special quota associated with the consumption type corresponding to the payment scene;

step 202c, detecting whether the quantity of resources required by the payment scene is larger than a target special limit or not;

if the quantity of the resources required by the payment scene is not greater than the target special limit, determining that the payment scene meets the use condition; and if the quantity of the resources required by the payment scene is greater than the target special limit, determining that the payment scene does not meet the use condition, and ending the process.

And 203, if the payment scene meets the use condition, completing the payment process through the resources in the payment token.

In the embodiment of the invention, the client of the payer receives the payment token in advance before completing the payment process, and completes the payment process through the resources in the payment token, thereby avoiding the condition that the client of the payer needs to confirm the on-line of the payment agent when requesting the payment agent, and improving the success rate and the efficiency of the payment.

Alternatively, step 203 may comprise several sub-steps as follows:

step 203a, the payment token option is displayed in the payment interface.

The payment interface refers to an interface displayed when the execution of the payment process is triggered. The payment interface comprises a payment mode list, the payment mode list comprises a payment token option, and the payment token option is used for triggering the payment token to complete a payment process. Optionally, other payment method options are also included in the payment method list, such as change payment, bank card payment, person-seeking payment and the like.

Optionally, the payment interface further includes an amount to be paid, an input entry of payment verification information, and a payment confirmation control. The amount to be paid refers to the amount of money required to be paid in the payment process. The input entry of the payment verification information is used for inputting the payment verification information. The payment confirmation control is used for confirming sending of the payment request.

Step 203b, receiving a selection signal corresponding to the payment token option and payment verification information input in the payment interface;

if the user desires to complete the payment process via the payment token, a payment token option may be selected in the payment method list. The payment verification information refers to information for verifying the identity of the user, and may be a password or a pattern preset by the user, fingerprint information of the user, or iris information of the user, which is not limited in the embodiment of the present invention.

In addition, the embodiment of the invention does not limit the sequence of receiving the selection signal corresponding to the payment token option and receiving the fingerprint verification information input in the payment interface. The payer client may receive a selection signal corresponding to the payment token option first, and then receive fingerprint authentication information input at the payment interface; the payer client may receive the fingerprint authentication information input at the payment interface first, and then receive a selection signal corresponding to the payment token option; a selection signal corresponding to the payment token option and fingerprint verification information input at the payment interface may also be received simultaneously.

Step 203c, a payment request is sent to the server.

The payment request is for requesting execution of a payment procedure. The payment request carries payment verification information. Optionally, the payment request further carries an amount to be paid, an identifier of the payment token, and an identifier of the payer client. Optionally, the payer client sends a payment request to the server upon receiving a trigger signal corresponding to the payment confirmation control.

Accordingly, the server receives a payment request sent by the payer client. And the server is used for transferring the resource in the payment token to the payee account when the payment verification information passes verification. Optionally, the server sends a payment completion notification to the payer client after the payment is completed, where the payment completion notification is used to notify the payer client that the payment process is completed. The payer client may update the available spending limit of the payment token according to the payment completion notification. Specifically, the payer client updates the difference between the available consumption amount of the payment token before payment and the consumption amount of the paid payment token to the available consumption amount of the payment token after payment. Optionally, when the usage condition of the payment token includes the available payment times, the payer client may further update the available payment times. Optionally, the server also sends a payment completion notification to the payer client that sent the payment token.

In a specific example, with reference to fig. 4 in combination, a flow chart of a payment replacement method according to an embodiment of the invention is shown. The user B sets a 'payment token' and sends the 'payment token' to a payer A, the A receives a token change prompt sent by the B, the A can see the token limit and the time limit of the B in an account of the A, then in mobile payment, the A proposes that the 'payment token' of the B needs to be used for payment, the A can directly use a payment password or a fingerprint of the A to confirm payment, the payment of the A is directly deducted from the 'payment token' of the B, and after the payment is finished, the system sends payment information to the A and the B to confirm.

And if the payment scene does not meet the use condition, the step of completing the payment process through the resources in the payment token is not executed.

In summary, according to the technical scheme provided by the embodiment of the invention, the payment token is obtained from the client of the payment assistant in advance before the payment process is completed, and then when the client of the payment assistant is in a payment scene, the payment process can be completed through the resources in the payment token, so that the situation that the client of the payment assistant needs to confirm the client of the payment assistant on line when requesting the payment assistant is avoided, and the success rate and the efficiency of the payment can be improved.

When the usage conditions include the available payment time and/or the available payment times, the payment token may be invalidated. Optionally, in an optional embodiment provided based on the embodiment shown in fig. 2, the online payment method further includes the following two steps:

step 301, detecting whether the payment token is invalid.

When the usage condition includes the available payment time, the payer client may detect whether the payment token is invalid according to the available payment time. Optionally, the payer client detects whether the payment token is invalid by detecting whether the current time exceeds the available payment time. If the current time exceeds the available payment time, the payment token is invalid; if the current time does not exceed the available payment time, the payment token is not expired. Illustratively, the available payment time is 26 days 7 months in 2018, and if the current time is 27 days 7 months in 2018, the payment token has expired. Optionally, the payer client detects whether the payment token is invalid or not at preset time intervals. The preset time can be set according to actual requirements, which is not limited in the embodiment of the present invention.

When the usage condition includes the available payment times, the payer client may detect whether the payment token is invalid according to the available payment times. Optionally, the payer client updates the used number of the payment token after completing the payment process through the resource in the payment token each time, and then detects whether the used number is smaller than the available payment number, if the used number is greater than or equal to the available payment number, it is determined that the payment token has failed, and if the used number is smaller than the available payment number, it is determined that the payment token has not failed.

Step 302, if the payment token is invalid and the payment token has the remaining resources, a token invalidation notification is sent to the server.

The token invalidation notification is used for notifying that the payment token is invalidated, that is, the payer client cannot complete the payment process by using the resource in the payment token. The token invalidation notification carries the residual resources, and the payment token also carries the identifier of the client of the payer.

Correspondingly, the server receives the token invalidation notification sent by the payer client, and then transfers the residual resources to the payer client according to the token invalidation notification.

In other possible embodiments, after receiving the payment token, the payer client sets a timer, where the timeout time of the timer is a time interval from the time when the payment token is received to the last time of the available payment time of the payment token, and when the timer times out, if there are remaining resources in the payment token, the payer client sends a token invalidation notification to the server.

step 301, detecting whether the payment token is invalid.

Step 303, if it is detected that the payment token is invalid and the payment token has the remaining resources, sending a token validation request to the server.

The token validation request is used to request that payment tokens that have expired and that there are resources remaining continue to be validated. The token validation request comprises the identification of the client of the payer, the identification of the payment token and the identification of the client of the payer corresponding to the payment token. Optionally, the token validation request further carries a reason for failure of the payment token. In one example, the reason for the failure of the payment token is that the available payment time has expired. In another example, the failure cause of the payment token is that the number of available payments is 0.

The server is used for forwarding the token validation request to the client of the payment token corresponding to the agent. And the depowerer client is used for sending a token validation notice to the server after receiving the confirmation instruction corresponding to the token validation request, and the token validation notice is used for informing the payment token to be validated continuously. The payment token continues to take effect, i.e. the payer client may continue to complete the payment procedure using the remaining resources in the payment token.

Optionally, after receiving the token validation request forwarded by the server, the client of the payment agent displays a first interface, where the first interface includes a first query message, and the first query message is used to query whether to enable the payment token to continue validation. When the client of the payment agent receives the confirmation indication corresponding to the inquiry message, sending a token validation notice to the server, and forwarding the token validation notice to the client of the payment agent by the server; when the depayler client receives the denial indication corresponding to the inquiry message, a first token invalidation notification is sent to the server, and the server forwards the first token invalidation notification to the payer client. The first token expiration notification is used to notify that the payment token continues to expire.

Optionally, the first interface may further include an input control for setting the available payment time and/or the available payment times, and the client of the payer may receive the available payment time and/or the available payment times re-input by the sending user before receiving the confirmation indication corresponding to the inquiry information. If the client of the payment agent does not receive the available payment time and/or the available payment times which are re-input before receiving the confirmation indication corresponding to the inquiry information, the available payment time and/or the available payment times are not included in the use condition of the payment token after the payment token is continuously validated.

In an optional embodiment provided based on the embodiment shown in fig. 2, the online payment method further includes the following steps: and if the quantity of the remaining resources in the payment token is smaller than a first threshold, sending a resource acquisition request to the server.

The first threshold may be set by a sending user corresponding to the client of the payer, may also be actually set by the number of receiving users corresponding to the client of the payer, and may also be set by default by the client of the payer or the client of the payer, which is not limited in the embodiments of the present invention. The resource acquisition request is for requesting supplemental resources. The resource acquisition request carries an identifier of a payer client, an identifier of a payment token and an identifier of a payer client corresponding to the payment token. Optionally, the resource obtaining request also carries the number of remaining resources.

The server is used for forwarding the resource acquisition request to the client of the payment depowerer corresponding to the payment token. The broker client is configured to receive an input amount of the supplemental resource and send a token reset request to the server, and the server is configured to transfer the supplemental resource to the payment token according to the token reset request. The token reset request is used to trigger the transfer of the supplemental resource into the payment token. Optionally, the token resetting request carries the number of the supplementary resource, an identifier of the client of the payer, and an identifier of the payment token.

Optionally, the payer client displays a second interface after receiving the resource acquisition request, wherein the second interface includes a second inquiry message and an input box for inputting the amount of the supplementary resource is included in the second interface. The second challenge message is used to challenge whether the resource is supplemented for the payment token. The payer client receives the amount of the supplementary resource input in the second interface, and sends a token reset request to the server after receiving a confirmation indication corresponding to the second inquiry message. In addition, when the payer client receives a denial indication corresponding to the inquiry message, a refund reminder is sent to the server, which forwards the refund reminder to the payer client. The refusal alert is to indicate to the payer client to refuse to replenish the payment token with the resource.

Referring to fig. 5, a flowchart of an online payment method according to an embodiment of the present invention is shown, which is applied to a client of a payment agent, and the method may include the following steps:

step 501, when a payment token generation instruction is acquired, a payment token setting interface is displayed.

The payment token generation indication is an operation signal for requesting generation of a payment token triggered by the user of the payer agent. The client of the payment agent is provided with a control for generating the payment token, and when the user of the payment agent clicks the control, the client of the payment agent obtains a payment token generation instruction. The payment token setting interface is used for the payment token parameters set by the user of the payment agent.

In a first possible implementation, the client of the payment agent displays a session interface; after a trigger signal corresponding to a menu control in a session interface is acquired, displaying a function menu, wherein the function menu comprises an operation control for sending a payment token; and after the trigger signal corresponding to the operation control is acquired, displaying a payment token setting interface. The session interface can be a single chat session interface or a group chat session interface.

Referring to fig. 6 in combination, which shows an interface schematic diagram for setting a payment token according to an embodiment of the present invention, a user B clicks a menu control 611 in a single chat session interface 61, then a terminal displays a function menu 612, the function menu 612 includes an operation control 613 for sending the payment token, the user clicks the operation control 613, the terminal jumps to a payment token setting interface 62, the payment token setting interface 62 includes a first input box 621 for setting an available consumption amount, a second input box 622 for setting an available consumption type, a third input box 623 for setting an available payment number, a fourth input box 624 for setting an available payment time, and a confirmation control 625, when the user finishes setting, clicks the confirmation control 625, then the terminal jumps to the single

chat session interface

61, 61 includes a prompt message 614, when the user a clicks the prompt message 614, the payment token can be viewed.

In a second possible implementation manner, the client of the payment agent displays a resource interface, the resource interface includes a setting option, when a trigger signal corresponding to the setting option is received, the client of the payment agent displays the setting interface, the setting interface includes an option for setting the payment token, and when a trigger signal corresponding to the option for setting the payment token is received, the client of the payment agent displays the setting interface of the payment token.

Referring to fig. 7 in combination, which shows an interface schematic diagram of setting a payment token according to another embodiment of the present invention, a user B clicks a setting control 712 in a resource interface 711 displayed on a first terminal 71, then the first terminal 71 displays a setting interface 713, the setting interface 713 includes an operation control 714 for setting the payment token, when the user B clicks the operation control 714, then the first terminal 71 skips to display a payment token setting interface 715, the payment token setting interface 715 includes a first input box 716 for setting a setting object, a second input box 717 for setting an available consumption amount, a third input box 718 for setting an available consumption type, a fourth input box 719 for setting an available payment number, a fifth input box 720 for setting an available payment time, and a confirmation control 721, when the user finishes setting, clicks the confirmation control 721, then, the first terminal 71 sends a payment token generation request to the server, the server generates a payment token according to the payment token generation request, and sends a payment token message to the second terminal 72, the second terminal 72 displays a notification message 722, and when the user a clicks the notification message 722, the payment token can be viewed.

Step 502, receiving payment token parameters and usage conditions input in a payment token setup interface.

The payment token parameters may include the amount of resources in the payment token, and the payer client that received the payment token.

With reference to the first possible implementation manner in step 501, if the payment token is set in the single chat session interface by the payer client, the other client in the single chat session interface is set as the payer client that receives the payment token by default, and the user does not need to reselect; if the client of the payment agent initiates setting of the payment token in the group chat session interface, the user can select one or more clients in the group chat session interface as the client of the payment agent receiving the payment token. In addition, if the user does not select the payer client for receiving the payment token in the group chat session interface, the sending terminal sets all clients in the group chat session interface as the payer client for receiving the payment token.

With reference to the second possible implementation manner in step 501, the client of the payment agent may select one or more contacts in the contact list, and then the sending terminal uses the client corresponding to the selected contact as the client of the payment party that receives the payment token according to the selection signal.

The usage condition refers to a condition that needs to be satisfied to complete a payment process with the payment token. The usage conditions include available consumption types. Optionally, the usage conditions further include an available payment time and/or an available payment number.

Step 503, sending a payment token generation request to the server.

The payment token request is for requesting generation of a payment token. The payment token generation request carries payment token parameters and usage conditions. Optionally, the payment token generation request further carries an identifier of the client of the payer.

The server is used for generating a payment token according to the payment token generation request, sending payment token information to a payer client indicated by the payment token parameters, wherein the payment token information carries the payment token and the use condition, the payer client is used for detecting whether the payment scene meets the use condition when the payer client is in the payment scene, and if the payment scene meets the use condition, completing a payment process through resources in the payment token.

Accordingly, the server receives a payment token generation request sent by the client of the payer.

Referring to fig. 8, a flow chart of an online payment method according to an embodiment of the invention is shown. The method can be applied to the implementation environment shown in fig. 1, and comprises the following steps:

step 801, displaying a payment token setting interface when the client of the payment agent obtains a payment token generation instruction.

In step 802, the client of the payment assistant receives the parameters and the use conditions of the payment token input in the payment token setting interface.

In an embodiment of the present invention, the use condition includes an available consumption type, an available payment time, and an available payment number.

In step 803, the client of the payer sends a request for generating a payment token to the server.

The payment token generation request carries payment token parameters and usage conditions.

In step 804, the server generates a payment token according to the payment token generation request.

The server sends a payment token message to the payer client indicated by the payment token parameter, step 805.

The payment token message carries the payment token and the use condition of the payment token.

Accordingly, the payer client receives the payment token message sent by the server.

In step 806, when in the payment scenario, the payer client detects whether the amount of resources required by the payment scenario is greater than the amount of available resources of the payment token.

In step 807, if the amount of resources required by the payment scenario is not greater than the amount of available resources, the payer client detects whether the consumption type corresponding to the payment scenario belongs to an available consumption type.

Step 808, if the consumption type corresponding to the payment scenario belongs to the available consumption type, detecting whether the payment time corresponding to the payment scenario is in the available payment time.

Step 809, if the payment time corresponding to the payment scenario is in the available payment time, detecting whether the payment times corresponding to the payment scenario are less than the available payment times.

Step 810, if the payment times corresponding to the payment scene are less than the available payment times, completing the payment process through the resources in the payment token.

The following are embodiments of the apparatus of the present invention that may be used to perform embodiments of the method of the present invention. For details which are not disclosed in the embodiments of the apparatus of the present invention, reference is made to the embodiments of the method of the present invention.

Referring to fig. 9, a block diagram of an online payment device provided by an embodiment of the invention is shown. The device has the function of realizing the client side of the payer, and the function can be realized by hardware or by hardware executing corresponding software. The apparatus may include: a message receiving module 901, a condition detecting module 902 and a payment module 903.

The message receiving module 901 is configured to receive a payment token message sent by a server, where the payment token message carries a payment token and a usage condition of the payment token, the usage condition refers to a condition that needs to be met when the payment token is used to complete a payment process, and the usage condition includes at least one of an available consumption amount, an available consumption type, an available payment time, and an available payment frequency.

A condition detecting module 902, configured to detect whether the payment scenario satisfies the usage condition when the payment scenario is in a payment scenario.

A payment module 903, configured to complete the payment process through the resource in the payment token if the payment scenario satisfies the usage condition.

In an optional embodiment provided based on the embodiment shown in fig. 9, the usage condition includes the available consumption amount, and the condition detecting module 902 is configured to:

detecting whether the quantity of resources required by the payment scene is larger than the available consumption amount or not;

and if the quantity of the resources required by the payment scene is not greater than the available consumption amount, determining that the payment scene meets the use condition.

In another alternative embodiment provided based on the embodiment shown in fig. 9, the usage condition includes the available consumption type, and the condition detecting module 902 is configured to:

detecting whether the consumption type corresponding to the payment scene belongs to the available consumption type;

and if the consumption type corresponding to the payment scene belongs to the available consumption type, determining that the payment scene meets the use condition.

In another alternative embodiment provided based on the embodiment shown in fig. 9, the usage condition further includes an available payment time; the condition detecting module 902 is configured to:

detecting whether the payment time corresponding to the payment scene is in the available payment time;

and if the payment time corresponding to the payment scene is in the available payment time, determining that the payment scene meets the use condition.

In another alternative embodiment provided based on the embodiment shown in fig. 9, the usage condition further includes an available payment number; the condition detecting module 902 is configured to:

detecting whether the payment times corresponding to the payment scene are larger than the available payment times or not;

and if the payment times corresponding to the payment scene are not more than the available payment times, determining that the payment scene meets the use condition.

In another optional embodiment provided based on the embodiment shown in fig. 9, the usage condition includes the available consumption amount and the available consumption type, the available consumption type includes n consumption types, the available consumption amount includes a dedicated amount respectively associated with the n consumption types, and n is an integer greater than 1;

the condition detecting module 902 is configured to:

if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a target special quota associated with the consumption type corresponding to the payment scene;

detecting whether the quantity of resources required by the payment scene is larger than the target special limit or not;

and if the quantity of the resources required by the payment scene is not greater than the target special limit, determining that the payment scene meets the use condition.

In another optional embodiment provided based on the embodiment shown in fig. 9, the payment module 903 is configured to:

displaying a payment token option in a payment interface, wherein the payment token option is used for triggering the completion of the payment process through the payment token;

receiving a selection signal corresponding to the payment token option and payment verification information input at the payment interface;

and sending a payment request to the server, wherein the payment request carries the payment verification information, and the server is used for transferring the resources in the payment token to a payee account when the payment verification information passes verification.

In another alternative embodiment provided based on the embodiment shown in fig. 9, please refer to fig. 10, the apparatus further includes: a failure detection module 904 and a first sending module 905.

A failure detection module 904 for detecting whether the payment token is failed.

A first sending module 905, configured to send a token invalidation notification to the server if it is detected that the payment token is invalid and there are remaining resources in the payment token, where the token invalidation notification is used to notify the server to transfer the remaining resources to a payer account corresponding to the payment token.

In another alternative embodiment provided based on the embodiment shown in fig. 9, please refer to fig. 10, the apparatus further includes: a failure detection module 904 and a second sending module 906.

A second sending module 906, configured to send a token validation request to the server if it is detected that the payment token is invalid and there are remaining resources in the payment token, where the server is configured to forward the token validation request to a client of a payer corresponding to the payment token, and the client of the payer is configured to send a token validation notification to the server after receiving a confirmation instruction corresponding to the token validation request, where the token validation notification is used to notify that the payment token continues to be validated.

In another alternative embodiment provided based on the embodiment shown in fig. 9, please refer to fig. 10, the apparatus further includes: a third transmitting module 907.

A third sending module 907, configured to send a resource obtaining request to the server if the number of remaining resources in the payment token is smaller than a first threshold, where the server is configured to forward the resource obtaining request to a client of a payer corresponding to the payment token, the client of the payer is configured to receive the input number of the supplemental resource and send a token resetting request to the server, and the server is configured to transfer the supplemental resource to the payment token according to the token resetting request.

Referring to fig. 11, a block diagram of an online payment device provided by an embodiment of the invention is shown. The device has the function of realizing the client side of the payer, and the function can be realized by hardware or by hardware executing corresponding software. The apparatus may include: an interface display module 1101, a receiving module 1102 and a request sending module 1103.

The interface display module 1101 is configured to display a payment token setting interface when the payment token generation instruction is acquired.

The receiving module 1102 is configured to receive payment token parameters and usage conditions input in the payment token setting interface, where the usage conditions refer to conditions that need to be met when a payment token is used to complete a payment process, and the usage conditions include at least one of an available consumption amount, an available consumption type, an available payment time, and an available payment number.

A request sending module 1103, configured to send a payment token generation request to a server, where the payment token generation request carries the payment token parameters and the usage conditions; the server is used for generating the payment token according to the payment token generation request, sending a payment token message to a payer client indicated by the payment token parameters, wherein the payment token message carries the payment token and the use condition, the payer client is used for detecting whether the payment scene meets the use condition or not when the payer client is in the payment scene, and if the payment scene meets the use condition, completing a payment process through resources in the payment token.

Fig. 12 is a block diagram illustrating a terminal 1200 according to an exemplary embodiment of the present invention. The terminal 1200 may be: a smart phone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III, motion video Experts compression standard Audio Layer 3), an MP4 player (Moving Picture Experts Group Audio Layer IV, motion video Experts compression standard Audio Layer 4), a notebook computer, or a desktop computer. Terminal 1200 may also be referred to by other names such as user equipment, portable terminal, laptop terminal, desktop terminal, and so forth.

In general, terminal 1200 includes: a processor 1201 and a memory 1202.

The processor 1201 may include one or more processing cores, such as a 4-core processor, an 8-core processor, or the like. The processor 1201 may be implemented in at least one hardware form of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 1201 may also include a main processor and a coprocessor, where the main processor is a processor for Processing data in an awake state, and is also called a Central Processing Unit (CPU); a coprocessor is a low power processor for processing data in a standby state. In some embodiments, the processor 1201 may be integrated with a GPU (Graphics Processing Unit) that is responsible for rendering and drawing content that the display screen needs to display. In some embodiments, the processor 1201 may further include an AI (Artificial Intelligence) processor for processing a computing operation related to machine learning.

Memory 1202 may include one or more computer-readable storage media, which may be non-transitory. Memory 1202 may also include high-speed random access memory, as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In some embodiments, a non-transitory computer readable storage medium in memory 1202 is used to store at least one instruction for execution by processor 1201 to implement the method of online payment on the side of a payer client and/or payer client provided by the method embodiments of the present invention.

In some embodiments, the terminal 1200 may further optionally include: a peripheral interface 1203 and at least one peripheral. The processor 1201, memory 1202, and peripheral interface 1203 may be connected by a bus or signal line. Various peripheral devices may be connected to peripheral interface 1203 via a bus, signal line, or circuit board. Specifically, the peripheral device includes: at least one of radio frequency circuitry 1204, display 1205, camera assembly 1206, audio circuitry 1207, positioning assembly 1208, and power supply 1209.

Peripheral interface 1203 may be used to connect at least one peripheral associated with I/O (Input/Output) to processor 1201 and memory 1202. In some embodiments, the processor 1201, memory 1202, and peripheral interface 1203 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1201, the memory 1202 and the peripheral device interface 1203 may be implemented on a separate chip or circuit board, which is not limited in this embodiment.

The Radio Frequency circuit 1204 is used for receiving and transmitting RF (Radio Frequency) signals, also called electromagnetic signals. The radio frequency circuit 1204 communicates with a communication network and other communication devices by electromagnetic signals. The radio frequency circuit 1204 converts an electric signal into an electromagnetic signal to transmit, or converts a received electromagnetic signal into an electric signal. Optionally, the radio frequency circuit 1204 comprises: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and so forth. The radio frequency circuit 1204 may communicate with other terminals through at least one wireless communication protocol. The wireless communication protocols include, but are not limited to: the world wide web, metropolitan area networks, intranets, generations of mobile communication networks (2G, 3G, 4G, and 5G), Wireless local area networks, and/or WiFi (Wireless Fidelity) networks. In some embodiments, the rf circuit 1204 may further include NFC (Near Field Communication) related circuits, which are not limited in this disclosure.

The display screen 1205 is used to display a UI (User Interface). The UI may include graphics, text, icons, video, and any combination thereof. When the display screen 1205 is a touch display screen, the display screen 1205 also has the ability to acquire touch signals on or over the surface of the display screen 1205. The touch signal may be input to the processor 1201 as a control signal for processing. At this point, the display 1205 may also be used to provide virtual buttons and/or a virtual keyboard, also referred to as soft buttons and/or a soft keyboard. In some embodiments, the display 1205 may be one, providing the front panel of the terminal 1200; in other embodiments, the display 1205 can be at least two, respectively disposed on different surfaces of the terminal 1200 or in a folded design; in still other embodiments, the display 1205 may be a flexible display disposed on a curved surface or on a folded surface of the terminal 1200. Even further, the display screen 1205 may be arranged in a non-rectangular irregular figure, i.e., a shaped screen. The Display panel 1205 can be made of LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), or other materials.

Camera assembly 1206 is used to capture images or video. Optionally, camera assembly 1206 includes a front camera and a rear camera. Generally, a front camera is disposed at a front panel of a terminal, and a rear camera is disposed at a rear surface of the terminal. In some embodiments, the number of the rear cameras is at least two, and each rear camera is any one of a main camera, a depth-of-field camera, a wide-angle camera and a telephoto camera, so that the main camera and the depth-of-field camera are fused to realize a background blurring function, and the main camera and the wide-angle camera are fused to realize panoramic shooting and VR (Virtual Reality) shooting functions or other fusion shooting functions. In some embodiments, camera assembly 1206 may also include a flash. The flash lamp can be a monochrome temperature flash lamp or a bicolor temperature flash lamp. The double-color-temperature flash lamp is a combination of a warm-light flash lamp and a cold-light flash lamp and can be used for light compensation under different color temperatures.

The audio circuitry 1207 may include a microphone and a speaker. The microphone is used for collecting sound waves of a user and the environment, converting the sound waves into electric signals, and inputting the electric signals into the processor 1201 for processing or inputting the electric signals into the radio frequency circuit 1204 to achieve voice communication. For stereo capture or noise reduction purposes, multiple microphones may be provided at different locations of terminal 1200. The microphone may also be an array microphone or an omni-directional pick-up microphone. The speaker is used to convert electrical signals from the processor 1201 or the radio frequency circuit 1204 into sound waves. The loudspeaker can be a traditional film loudspeaker or a piezoelectric ceramic loudspeaker. When the speaker is a piezoelectric ceramic speaker, the speaker can be used for purposes such as converting an electric signal into a sound wave audible to a human being, or converting an electric signal into a sound wave inaudible to a human being to measure a distance. In some embodiments, the audio circuitry 1207 may also include a headphone jack.

The positioning component 1208 is configured to locate a current geographic Location of the terminal 1200 to implement navigation or LBS (Location Based Service). The Positioning component 1208 can be a Positioning component based on the Global Positioning System (GPS) in the united states, the beidou System in china, or the galileo System in russia.

The power supply 1209 is used to provide power to various components within the terminal 1200. The power source 1209 may be alternating current, direct current, disposable or rechargeable. When the power supply 1209 includes a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. The wired rechargeable battery is a battery charged through a wired line, and the wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery may also be used to support fast charge technology.

In some embodiments, terminal 1200 also includes one or more sensors 1210. The one or more sensors 1210 include, but are not limited to: acceleration sensor 1211, gyro sensor 1212, pressure sensor 1213, fingerprint sensor 1214, optical sensor 1215, and proximity sensor 1216.

The acceleration sensor 1211 can detect magnitudes of accelerations on three coordinate axes of the coordinate system established with the terminal 1200. For example, the acceleration sensor 1211 may be used to detect components of the gravitational acceleration in three coordinate axes. The processor 1201 may control the touch display 1205 to display the user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1211. The acceleration sensor 1211 may also be used for acquisition of motion data of a game or a user.

The gyro sensor 1212 may detect a body direction and a rotation angle of the terminal 1200, and the gyro sensor 1212 may collect a 3D motion of the user on the terminal 1200 in cooperation with the acceleration sensor 1211. The processor 1201 can implement the following functions according to the data collected by the gyro sensor 1212: motion sensing (such as changing the UI according to a user's tilting operation), image stabilization while shooting, game control, and inertial navigation.

Pressure sensors 1213 may be provided on the side bezel of terminal 1200 and/or on the lower layer of touch display 1205. When the pressure sensor 1213 is disposed on the side frame of the terminal 1200, the user's holding signal of the terminal 1200 can be detected, and the processor 1201 performs left-right hand recognition or shortcut operation according to the holding signal collected by the pressure sensor 1213. When the pressure sensor 1213 is disposed at a lower layer of the touch display screen 1205, the processor 1201 controls the operability control on the UI interface according to the pressure operation of the user on the touch display screen 1205. The operability control comprises at least one of a button control, a scroll bar control, an icon control, and a menu control.

The fingerprint sensor 1214 is used for collecting a fingerprint of the user, and the processor 1201 identifies the user according to the fingerprint collected by the fingerprint sensor 1214, or the fingerprint sensor 1214 identifies the user according to the collected fingerprint. When the identity of the user is identified as a trusted identity, the processor 1201 authorizes the user to perform relevant sensitive operations, including unlocking a screen, viewing encrypted information, downloading software, paying, changing settings, and the like. The fingerprint sensor 1214 may be provided on the front, back, or side of the terminal 1200. When a physical button or vendor Logo is provided on the terminal 1200, the fingerprint sensor 1214 may be integrated with the physical button or vendor Logo.

The optical sensor 1215 is used to collect the ambient light intensity. In one embodiment, the processor 1201 may control the display brightness of the touch display 1205 according to the ambient light intensity collected by the optical sensor 1215. Specifically, when the ambient light intensity is high, the display brightness of the touch display panel 1205 is increased; when the ambient light intensity is low, the display brightness of the touch display panel 1205 is turned down. In another embodiment, processor 1201 may also dynamically adjust the shooting parameters of camera assembly 12012 based on the ambient light intensity collected by optical sensor 1215.

A proximity sensor 1216, also known as a distance sensor, is typically disposed on the front panel of the terminal 1200. The proximity sensor 1216 is used to collect a distance between the user and the front surface of the terminal 1200. In one embodiment, when the proximity sensor 1216 detects that the distance between the user and the front surface of the terminal 1200 gradually decreases, the processor 1201 controls the touch display 1205 to switch from the bright screen state to the dark screen state; when the proximity sensor 1216 detects that the distance between the user and the front surface of the terminal 1200 gradually becomes larger, the processor 1201 controls the touch display 1205 to switch from the breath screen state to the bright screen state.

Those skilled in the art will appreciate that the configuration shown in fig. 12 is not intended to be limiting of terminal 1200 and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components may be used.

In an exemplary embodiment, there is also provided a computer readable storage medium having stored therein at least one instruction, at least one program, code set or set of instructions, which is loaded and executed by a processor of an electronic device to implement the online payment method on the side of a payer client and/or a payer client in the above method embodiments.

Alternatively, the computer-readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, there is also provided a computer program product for performing the above-described online payment method on the side of the payer client and/or the payer client, when the computer program product is executed.

It should be understood that reference to "a plurality" herein means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. As used herein, the terms "first," "second," and the like, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

The present invention is not limited to the above exemplary embodiments, and any modifications, equivalent replacements, improvements, etc. within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. An online payment method applied to a payer client, the method comprising:

receiving a payment token message sent by a server, and displaying a notification message, wherein the notification message is used for a payer user to click to view the payment token; the payment token message carries the payment token and the using condition of the payment token, wherein the payment token carries resources, and the payment token is a virtual carrier for transferring the resources in a donation form between at least two users; the use condition refers to a condition which needs to be met when the payment token is adopted to complete the payment process, the use condition comprises n available consumption types and a special quota which is respectively associated with the n available consumption types, n is an integer which is greater than 1, the available consumption types refer to consumption types which allow the payment process to be completed through resources in the payment token, and the available consumption types are set by a payment-on-behalf user; the server generates the payment token according to a payment token generation request sent by a client of a payer, and then sends a payment token message to the client of the payer;

when the payment scene is in the payment scene, detecting whether the payment scene meets the use condition or not, wherein the detecting comprises the following steps:

detecting whether the consumption type corresponding to the payment scene belongs to an available consumption type;

if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a special quota associated with the consumption type corresponding to the payment scene;

detecting whether the quantity of resources required by the payment scene is larger than the special limit or not;

if the payment scene meets the use condition, completing the payment process through the resources in the payment token, wherein when the quantity of the resources required by the payment scene is not greater than the special limit, the payment scene is determined to meet the use condition;

if the payment token is detected to be invalid and the remaining resources exist in the payment token, sending a token invalidation notification to the server, wherein the token invalidation notification is used for notifying the server to transfer the remaining resources to a payer account corresponding to the payment token;

wherein said completing the payment process through the resource in the payment token comprises:

displaying a payment token option in a payment interface, wherein the payment token option is used for triggering completion of the payment process through the payment token, the payment token option is displayed in a payment mode list, and the payment mode list further comprises other payment mode options;

and sending a payment request to the server, wherein the payment request carries the payment verification information and the identifier of the payment token, and the server is used for transferring the resource in the payment token to a payee account when the payment verification information passes verification.

2. The method of claim 1, wherein the usage conditions further include available spending limits, and wherein the usage conditions further include: the amount of resources required by the payment scenario is not greater than the available consumption amount.

3. The method of claim 1, wherein the usage conditions further include an available payment time, and wherein the usage conditions further include: and the payment time corresponding to the payment scene is in the available payment time.

4. The method of claim 1, wherein the usage conditions further include an available payment number, and wherein the usage conditions further include: and the payment times corresponding to the payment scenes are not more than the available payment times.

5. The method of any of claims 1 to 4, wherein completing the payment process via the resource in the payment token further comprises:

detecting whether the payment token is invalid;

if the payment token is detected to be invalid and the payment token has residual resources, sending a token validation request to the server, wherein the server is used for forwarding the token validation request to a client of a payment agent corresponding to the payment token, the client of the payment agent is used for sending a token validation notification to the server after receiving a confirmation instruction corresponding to the token validation request, and the token validation notification is used for notifying the payment token to continuously take effect.

6. The method according to any one of claims 1 to 4, wherein after receiving the payment token message sent by the server, the method further comprises:

if the number of the remaining resources in the payment token is smaller than a first threshold, sending a resource acquisition request to the server, wherein the server is used for forwarding the resource acquisition request to a client of a payment agent corresponding to the payment token, the client of the payment agent is used for receiving the input number of the supplementary resources and sending a token resetting request to the server, and the server is used for transferring the supplementary resources to the payment token according to the token resetting request.

7. An online payment method applied to a client of a payer, the method comprising:

when a payment token generation instruction is acquired, displaying a payment token setting interface; when a payer user clicks a control of the client of the payer for generating a payment token, acquiring a payment token generation instruction;

receiving payment token parameters and use conditions input in the payment token setting interface, wherein the use conditions refer to conditions required to be met by completing a payment process by adopting a payment token, the use conditions comprise n available consumption types and respective associated special lines of the n available consumption types, n is an integer larger than 1, the available consumption types refer to consumption types allowing the payment process to be completed through resources in the payment token, and the available consumption types are set by a payment-on-behalf user;

sending a payment token generation request to a server, wherein the payment token generation request carries the payment token parameters and the use conditions; the server is used for generating the payment token according to the payment token generation request and then sending a payment token message to a payer client indicated by the payment token parameter, wherein the payment token message carries the payment token and the use condition, the payment token carries resources, and the payment token is a virtual carrier for transferring the resources between at least two users in a donation form;

the payer client is used for detecting whether the consumption type corresponding to the payment scene belongs to the available consumption type when the payer client is in the payment scene; if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a special quota associated with the consumption type corresponding to the payment scene; detecting whether the quantity of resources required by the payment scene is larger than the special limit or not; if the quantity of the resources required by the payment scene is not larger than the special limit, completing the payment process through the resources in the payment token;

8. An online payment device, applied in a payer client, the device comprising:

the payment system comprises a message receiving module, a payment token processing module and a payment processing module, wherein the message receiving module is used for receiving a payment token message sent by a server and displaying a notification message, and the notification message is used for a payer user to click to view the payment token; the payment token message carries the payment token and a use condition of the payment token, wherein the payment token carries resources, the payment token is a virtual carrier for transferring resources in a donation form between at least two users, the use condition refers to a condition which needs to be met when the payment token is adopted to complete a payment process, the use condition includes n available consumption types and a special quota which is respectively associated with the n available consumption types, n is an integer greater than 1, the available consumption type refers to a consumption type which allows the payment process to be completed through the resources in the payment token, and the available consumption type is set by a payment-taking-over user; the server generates the payment token according to a payment token generation request sent by a client of a payer, and then sends a payment token message to the client of the payer;

the condition detection module is used for detecting whether the payment scene meets the use condition when the payment scene is in the payment scene, and comprises the following steps: detecting whether the consumption type corresponding to the payment scene belongs to an available consumption type; if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a special quota associated with the consumption type corresponding to the payment scene; detecting whether the quantity of resources required by the payment scene is larger than the special limit or not;

the payment module is used for completing the payment process through the resources in the payment token if the payment scene meets the use condition, wherein when the quantity of the resources required by the payment scene is not greater than the special limit, the payment scene is determined to meet the use condition; wherein said completing the payment procedure through the resource in the payment token comprises: displaying a payment token option in a payment interface, wherein the payment token option is used for triggering completion of the payment process through the payment token, the payment token option is displayed in a payment list, and the payment list further comprises other payment mode options; receiving a selection signal corresponding to the payment token option and payment verification information input at the payment interface; sending a payment request to the server, wherein the payment request carries the payment verification information, and the server is used for transferring the resource in the payment token to a payee account when the payment verification information passes verification;

and the second sending module is used for sending a failure notice to the server if the payment token is detected to be failed and the remaining resources exist in the payment token, wherein the token failure notice is used for informing the server of transferring the remaining resources to the payer account corresponding to the payment token.

9. An online payment apparatus, applied in a client of a payer, the apparatus comprising:

the acquisition module is used for acquiring a payment token generation instruction when a payer user clicks a control used for generating a payment token of the client of the payer;

a receiving module, configured to receive payment token parameters and usage conditions input in the payment token setting interface, where the usage conditions are conditions that need to be met when a payment token is used to complete a payment process, the usage conditions include n available consumption types and dedicated quota associated with each of the n available consumption types, where n is an integer greater than 1, the available consumption types are consumption types that allow a payment process to be completed through resources in the payment token, and the available consumption types are set by a payment-for-use user;

a request sending module, configured to send a payment token generation request to a server, where the payment token generation request carries the payment token parameters and the usage conditions, where the server is configured to send a payment token message to a payer client indicated by the payment token parameters after generating the payment token according to the payment token generation request, where the payment token carries resources, the payment token is a virtual carrier for transferring resources in a donation form between at least two users, and the payment token message carries the payment token and the usage conditions; the payer client is used for detecting whether the consumption type corresponding to the payment scene belongs to the available consumption type when the client is in the payment scene; if the consumption type corresponding to the payment scene belongs to the available consumption type, acquiring a special quota associated with the consumption type corresponding to the payment scene; detecting whether the quantity of the resources required by the payment scene is greater than the special limit, and if the quantity of the resources required by the payment scene is not greater than the special limit, completing the payment process through the resources in the payment token;

wherein said completing the paid flow through the resource in the payment token comprises:

10. A terminal, characterized in that it comprises a processor and a memory, in which at least one instruction, at least one program, a set of codes or a set of instructions is stored, which is loaded and executed by the processor to implement the online payment method according to any one of claims 1 to 6, or the online payment method according to claim 7.

11. A computer readable storage medium having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions, which is loaded and executed by a processor to implement the online payment method of any one of claims 1 to 6, or the online payment method of claim 7.