CN110033246B

CN110033246B - Network payment current limiting control method and device

Info

Publication number: CN110033246B
Application number: CN201811496497.5A
Authority: CN
Inventors: 周书
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-12-07
Filing date: 2018-12-07
Publication date: 2024-01-12
Anticipated expiration: 2038-12-07
Also published as: CN110033246A

Abstract

The invention provides a payment control method, which comprises the following steps: receiving transaction requests from a plurality of users, each transaction request including an ID of the user sending the transaction request; passing a first threshold number of transaction requests through a first streaming limit node; determining a primary payment instrument associated with each transaction request through the first streaming node based on the user's ID and determining whether the primary payment instrument is an idle payment instrument or an overloaded payment instrument; recommending idle payment instruments to the master payment instrument for a subset of users of the overloaded payment instruments; and throttling the transaction requests for each payment instrument at the second throttling node.

Description

Network payment current limiting control method and device

Technical Field

The invention mainly relates to the technical field of Internet application, in particular to a network payment current limiting control method and device.

Background

With the rapid development of economy and network technology, online shopping becomes one of the main shopping channels of consumers, and more payment tools for online transaction, such as contracted quick bank cards, balance treasures, and cut, are used, so that the transaction between a payer and a payee is more convenient and quicker.

At present, in terms of coping with transaction payment peaks, the payment link has two key nodes: the overall payment capacity flow limit of the cash register link and the branch payment tool capacity flow limit after entering the payment link.

However, the following problems are caused by the uneven distribution of the capacity of each main payment tool and the usage habit of the user: first, some payment instrument capacity is overloaded, causing a large number of users to pay overtime or fail, while other payment instrument capacity is underutilized, resulting in wasted capacity. Secondly, after entering the payment link, the user is limited with current to cause payment failure, and the user also withdraws the cash recycling link to select other payment tools for payment, so that the user experience is affected.

Accordingly, there is a need for a payment current limit control scheme that addresses the above issues.

Disclosure of Invention

The invention aims to provide an efficient payment current limiting method, which fully utilizes various payment tool resources and improves the smoothness of payment.

In order to solve the technical problems, the present invention provides a payment control method, including:

receiving transaction requests from a plurality of users, each transaction request including an ID of the user sending the transaction request;

passing a first threshold number of transaction requests through a first streaming limit node;

determining a primary payment instrument associated with each transaction request through the first streaming node based on the user's ID and determining whether the primary payment instrument is an idle payment instrument or an overloaded payment instrument;

recommending idle payment instruments to the master payment instrument for a subset of users of the overloaded payment instruments; and

the transaction request is throttled at the second throttle node for each payment instrument.

Optionally, the method further comprises,

determining a total number of transaction requests associated with each payment instrument; and

the total number of transaction requests associated with each payment instrument is compared to a preset target value for the payment instrument to determine whether the payment instrument is an idle payment instrument or an overloaded payment instrument.

Optionally, the method further comprises determining that the payment instrument is an idle payment instrument if the total number of transaction requests associated with the payment instrument is below a preset target value for the payment instrument.

Optionally, the method further comprises determining that the payment instrument is an overloaded payment instrument if the total number of transaction requests associated with the payment instrument is above a preset target value for the payment instrument.

Optionally, the preset target value is updated in real time according to a change in capacity of each payment instrument.

Optionally, the preset target value is determined according to a capacity threshold set at the second current limiting node for each payment instrument.

Optionally, the subset of users recommended for the idle payment instrument is selected based on user usage habits and/or historical payment success rates.

Optionally, the method further comprises sending a transaction request through the second streaming node to a payment link.

Another aspect of the present invention provides a payment control apparatus, comprising:

a receiving module configured to receive transaction requests from a plurality of users, each transaction request including an ID of a user that sent the transaction request;

a first current limiting module configured to:

determining from the user's ID the associated transaction request for each transaction through the first streaming node

A master payment instrument and determining whether the master payment instrument is an idle payment instrument or an overloaded payment instrument; and recommending an idle payment instrument to the primary payment instrument for a subset of users of the overloaded payment instrument; and

a second throttling module configured to throttle the transaction request at the second throttling node for each payment instrument.

Optionally, the first current limit module is further configured to determine whether each payment instrument is an idle payment instrument or an overloaded payment instrument based on the total number of transaction requests associated with that payment instrument.

Optionally, the first current limiting module is further configured to: if the total number of transaction requests associated with a payment instrument is below a preset target value for the payment instrument, the payment instrument is determined to be an idle payment instrument.

Optionally, the first current limiting module is further configured to: if the total number of transaction requests associated with a payment instrument is above a preset target value for the payment instrument, the payment instrument is determined to be an overloaded payment instrument.

Optionally, the apparatus further comprises a transmitting module configured to send a transaction request through the second streaming node to a payment link.

Still another aspect of the present invention provides a payment control apparatus, comprising:

a processor; and

a memory arranged to store computer executable instructions that, when executed, cause the processor to:

receiving transaction requests from a plurality of users, each transaction request including a use to send the transaction request

The ID of the user;

A master payment instrument and determining whether the master payment instrument is an idle payment instrument or an overloaded payment instrument;

In the prior art, only the whole payment capacity is limited in the cash collecting link, so that the capacity of each payment tool cannot be fully utilized when the large-flow payment peak value occurs.

According to the invention, the granularity current limitation of the front-end payment tool is added in the cashing link, and the idle payment tool is recommended to the user, so that various payment tools can be fully utilized. The invention also senses the capacity change condition of the downstream payment tool (for example, abnormal bank card, reduced capacity of a bank card channel), selects the user which is most suitable for being limited and recommending other payment tools, improves the user payment success rate, reduces the user switching rate and ensures smooth user payment.

Drawings

Fig. 1 is a schematic diagram of a payment link flow restriction.

Fig. 2 is a flow chart of entering a payment link in the prior art.

Fig. 3 illustrates one example of a prior art payment link flow restriction.

Fig. 4 illustrates an example of payment link throttling in accordance with aspects of the invention.

FIG. 5 illustrates an interface diagram for recommending use of a payment instrument to a user.

Fig. 6 illustrates a flow chart of a payment instrument current limiting method in accordance with the present invention.

Fig. 7 is a flow chart of a method for payment instrument current limiting in accordance with the present invention.

Fig. 8 is a block diagram of an apparatus for a payment instrument current limiting method according to the present invention.

Detailed Description

In order to make the above objects, features and advantages of the present invention more comprehensible, embodiments accompanied with figures are described in detail below.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention, but the present invention may be practiced in other ways than as described herein, and therefore the present invention is not limited to the specific embodiments disclosed below.

In network payment, there are two metrics as to whether the user pays smoothly: a payment success rate and a user payment instrument switching rate.

The payment success rate is the ratio of the number of successful payments to the number of requests for payment. The user payment instrument switching rate is a ratio of the number of payments by which the user switches the payment instrument to the number of payment requests. In general, the higher the payment success rate, the lower the user payment instrument switching rate, and the higher the smoothness of the payment.

The application aims to provide a method for improving payment smoothness under the condition of insufficient overall payment capacity.

Fig. 1 is a schematic diagram of a payment link capacity throttling scheme, and fig. 2 is a flow chart of a payment link throttling process in the prior art.

As shown in fig. 1 and 2, the payment link has two links: a cashing link and a payment link.

Specifically, after a user initiates a transaction request (also referred to herein as a payment request) (e.g., clicks on the panning "confirm purchase/submit order" button), a cashier link may be entered. In the cash register link, the application jumps out of the cash register interface, the cash register interface displays a plurality of payment tools, and the user is prompted to select one of the payment tools for payment. Alternatively, the checkout counter interface may also display default payment instruments and entries for selecting other payment instruments. After the user determines the payment instrument to be used for payment and clicks the "confirm payment" button, the payment link is entered.

Accordingly, the transaction request capacity throttling on the payment link is divided into two nodes:

the first node is a cashing link current limit, also referred to as an overall current limit, which limits the overall transaction request traffic, protecting the overall payment link. At the peak of the transaction, the total number of transaction requests may be greater than the total capacity of the payment channel. The cash register link limits the flow to allow the transaction requests with the quantity smaller than or equal to the total capacity of the payment channel to enter the cash register link, and other transaction requests with the flow limit are queued to wait for entering the cash register link. The overall throttling is typically based on the time that the transaction request was received, with later received requests being more likely to be throttled. And thus cannot control the payment instrument requested by the current limit in the overall current limit.

The second node is a payment link restriction (also referred to as a branch payment instrument restriction). After entering the payment link, the system performs current limiting according to the capacities of various payment tools. Specifically, a capacity threshold is set for each payment instrument, and if the number of users selecting the payment instrument is greater than the capacity threshold, the system only allows a number of transaction requests equal to the capacity threshold to enter payment, and other transaction requests are queued.

In some examples, the transaction fails if the queuing exceeds a threshold time.

Fig. 3 illustrates one example of a prior art payment link flow restriction.

As shown in fig. 3, four payment instruments A, B, C and D may be used in the transaction, which may be e.g. a bank card, a transaction, a balance treasury, a balance of a payment treasury, etc.

These transaction requests include 6 ten thousand requests to use payment instrument a,6 ten thousand requests to use payment instrument B,2 ten thousand requests to use payment instrument C, and 2 ten thousand requests to use payment instrument D. Note that here, the payment instrument to which each request corresponds is a default payment instrument determined by the system according to the setting and/or payment habit of the user of the request, and the like. For example, it is typically displayed as a default payment instrument on the checkout counter interface, or in the first place in a list of payment instruments. That is, among the users requesting the transaction, 6 ten thousand users use the payment instrument a by default, 6 ten thousand users use the payment instrument B by default, 2 ten thousand users use the payment instrument C by default, and 2 ten thousand users use the payment instrument D by default. For simplicity, these requests are also referred to herein as a payment instrument a request, a payment instrument B request, a payment instrument C request, and a payment instrument D request, respectively. It should be appreciated that the amounts given herein are exemplary only and not limiting.

In the example of fig. 3, the overall capacity of the cashier link is limited to 8 tens of thousands. After the capacity flow limitation of the cashing link, 3 ten thousand payment instrument A requests, 3 ten thousand payment instrument B requests, 1 ten thousand payment instrument C requests and 1 ten thousand payment instrument D requests enter the payment link through the flow limitation. The remaining transaction requests are queued for throttling through the cashing link.

In the payment link current limiting, current limiting is performed on various payment tool capacities respectively. As shown in fig. 3, the capacity thresholds defined for tools A, B, C and D in the payment link are 2 tens of thousands, 4 tens of thousands, 1 tens of thousands, and 1 tens of thousands, respectively. The number of payment instrument a requests limited by the cashing link (3 tens of thousands) is greater than the capacity threshold defined by the payment link for instrument a (2 tens of thousands), thus leaving ten thousands of payment instrument a requests to be queued in the payment link, resulting in a timeout or failure of these user payments. The number of requests (3 ten thousand) of the payment tool B limited by the cash-receiving link is ten thousand less than the capacity threshold (4 ten thousand) defined by the payment link for the tool A, so that the capacity of 1 ten thousand of the payment tools B is not utilized, and the resource waste is caused. It follows that prior art payment instrument current limited allocations result in an imbalance in resource allocation.

In view of the above problems, the present invention proposes a method for improving the smoothness of payment in the case of insufficient overall payment capacity. Specifically, in the cash flow limit, the branch payment tool flow limit and the payment tool recommendation are added on the basis of the integral flow limit. For example, the system flexibly adjusts the duty cycle allocation of various payment instruments based on the overall capacity satisfying the limit according to the capacity of each payment instrument. This may be achieved by recommending a payment instrument that pays smoother downstream to a user that is overloaded with default payment instruments. For example, the user is guided to use a more idle payment instrument with a higher payment success rate, thereby improving the user's overall payment success rate and reducing the user's payment instrument switching rate, and enabling resources to be efficiently utilized.

As shown in fig. 4, the cashier link can be divided into two stages. In the first stage, the payment request is overall limited, as shown in fig. 3.

Compared with the prior art, the invention adds a second stage in the cashing link, and sets a target value for each payment tool in the second stage, wherein the target value can be set according to the capacity threshold value set for the payment tool in the current limiting of the subsequent payment link, and the sum of the target values of each payment tool meets (i.e. is smaller than or equal to) the whole capacity value of the cashing link.

For convenience of explanation, in this example, the target value set for each payment instrument in the second stage of the cashing link is the same as the capacity threshold set for each payment instrument in the payment link, but the target value set for each payment instrument in the cashing link and the capacity threshold set for each payment instrument in the payment link may be different. For example, in the case where the overall capacity of the cashier link is greater, the target value of the cashier link may also be greater than the capacity threshold of the payment link, e.g., the target value of the cashier link may be a scaling of the capacity threshold of the payment link.

Further, the target value set for each payment instrument in the second stage of the cashing link can be dynamically adjusted. The system can sense the capacity change of each payment instrument at the downstream. For example, abnormal jitter of a bank channel may cause the bank capacity to become smaller, thereby reducing the capacity threshold set by the payment link limiting node for the bank card. In this case, the target value set for the bank card in the cashier link can be reduced accordingly.

As shown in fig. 4, there are 6 tens of thousands of payment instrument a requests, 6 tens of thousands of payment instrument B requests, 2 tens of thousands of payment instrument C requests, and 2 tens of thousands of payment instrument D requests in the transaction request.

After the overall capacity flow restriction in the first stage of the cashing link, 3 ten thousand payment instrument a requests, 3 ten thousand payment instrument B requests, 1 ten thousand payment instrument C requests and 1 ten thousand payment instrument D requests enter the second stage of the cashing link through the flow restriction, as shown in fig. 3.

In this example, the second stage of the cashing link sets target values of 2 ten thousand, 4 ten thousand, 1 ten thousand, and 1 ten thousand for the four payment instruments, respectively. It follows that payment instrument a requests (3 ten thousand) 1 ten thousand more than payment instrument a target value (2 ten thousand), while payment instrument B requests (3 ten thousand) 1 ten thousand less than payment instrument B target value (4 ten thousand).

The system may thus determine that payment instrument a is an overloaded payment instrument, and payment instrument B is a relatively idle payment instrument. The system may further determine that payment instrument B is to be recommended to some users of payment instrument a.

In the second stage of the cashing link, the system selects 1 ten thousand users from among the users of the 3 ten thousand payment instruments a according to various recommendation algorithms, and recommends the users to use the more idle payment instrument B. The recommendation algorithm may take into account, for example, user habits, historical payment success rates, waiting times, and so forth.

FIG. 5 illustrates an interface diagram for recommending use of a payment instrument to a user. Preferably, the interface diagram recommending payment instruments to the user may display the projected queue time for the user to consider whether to switch.

In an ideal case, after the recommending step of the cashing link, 1 ten thousand users using the payment instrument a select to pay using the payment instrument B instead. As a result, the final restriction through the cashing link is 2 tens of thousands of payment instrument a requests, 4 tens of thousands of payment instrument B requests, 1 tens of thousands of payment instrument C requests, and 1 tens of thousands of payment instrument D requests, entering the payment link. In the payment link flow limiting, flow limiting queuing is eliminated, and the total payment quantity is improved by 1 ten thousand compared with the prior art.

Regarding payment instrument recommendation, the system may determine which users among users using overloaded payment instruments to select to recommend other free payment instruments based on factors such as user payment habits, historical payment success rate, waiting time, etc., thereby reducing user payment instrument switching rate.

For example, the system may recommend the use of the payment instrument B to a user who uses the payment instrument B frequently among users who default to use the payment instrument a, so that the success rate of recommendation may be improved. Alternatively, the system may recommend payment instruments to users based on their historical success rates of payment, e.g., some users may be recommended to use a bank card if their success rates are high (e.g., the balance on the bank card is sufficient).

Note that although only an example of recommending one type of payment instrument is shown in the examples of fig. 4 and 5, two or more types of payment instruments may be recommended to the user in a case where two or more types of payment instruments are idle, and the order of recommendation may refer to the user's payment habits or the historical success rate of the user's payment.

The payment link is entered by a payment request from the cashing link, which defines a capacity threshold for each payment instrument, which can be determined based on the downstream payment instrument capacity change. The cash flow limit is used for limiting the flow of transaction requests for each payment tool, allowing the payment requests smaller than or equal to the capacity threshold of the payment tool to pass through, entering a payment link, and queuing the payment requests exceeding the capacity threshold.

Fig. 6 illustrates a flow chart of a payment instrument current limiting method in accordance with aspects of the present invention.

In step 601, transaction requests from a plurality of users are received, the transaction requests including at least a user Identity (ID) of a requested transaction.

At step 602, the transaction requests are globally throttled according to the requirements of a first throttling node (e.g., a cashier throttling node).

For example, step 602 may correspond to the first stage of the cashier link described above.

In particular, it may be defined that only a certain threshold number of transaction requests can be passed in the first streaming node. The remaining transaction requests need to be queued up through the first streaming node.

In step 603, the primary payment instrument associated with each requesting user through the overall current limit is determined based on the user ID.

The primary payment instrument may be a default payment instrument stored in the system for use by the user. Specifically, the system may store for each user its corresponding default payment instrument, which may be set by the user himself or may be determined by the system according to the user's payment habits. The system may look up in its memory based on the user ID to determine the user's default payment instrument.

In step 604, the number of transaction requests corresponding to each payment instrument is counted.

In step 605, a target value for each payment instrument in a first throttling node is set according to a capacity threshold set by a second throttling node (e.g., a payment link throttling node) for the corresponding payment instrument.

The target value may be set in accordance with a capacity threshold set for the payment instrument in a subsequent payment segment current limit, and the sum of the target values for each payment instrument satisfies (i.e., is less than or equal to) the overall capacity value for the cashier segment.

At step 606, the number of transaction requests for each payment instrument is compared to the target value for that payment instrument to determine an overloaded payment instrument and an idle payment instrument.

For example, a payment instrument for which the transaction request data amount is greater than the target value is determined as an overloaded payment instrument, and a payment instrument for which the transaction request data amount is less than the target value is determined as an idle payment instrument.

In step 607, the use of the idle payment instrument is recommended to the user associated with the overloaded payment instrument.

As shown in fig. 6, the user may be prompted on the user's mobile phone interface to use a payment instrument with a higher payment success rate.

At step 608, the transaction request is throttled at the second throttle node for each payment instrument.

Steps 603-608 may correspond to the second phase of the cashier link described above.

At step 609, a transaction request is sent to the payment link through the second streaming node.

The second throttling node (e.g., a payment link throttling node) sets a capacity threshold for each payment instrument. The capacity threshold may be dynamically adjusted based on downstream payment instrument capacity changes. The second throttling node throttles for each payment instrument, allows payment requests less than or equal to the capacity threshold of the payment instrument to pass through, enters the payment link, and payment requests exceeding the capacity threshold need to be queued.

Note that the flow diagrams are described above in a particular order, but the order of the steps may also be interchanged. For example, the setting of the target value for each payment instrument in step 605 may also precede any of steps 601, 602, 603 and 604.

FIG. 7 illustrates a flow chart of a payment instrument current limiting method in accordance with aspects of the present invention.

In step 701, transaction requests from a plurality of users are received.

At step 702, a first threshold number of transaction requests are passed through a first streaming limit node.

In step 703, a payment instrument associated with each transaction request through the first streaming node is determined.

At step 704, a determination is made as to whether the primary payment instrument associated with each transaction request through the first streaming node is an idle payment instrument or an overloaded payment instrument.

For example, if the number of transaction requests associated with a payment instrument is below a preset target value for the payment instrument, the payment instrument is determined to be an idle payment instrument, and if the number of transaction requests associated with a payment instrument is above the preset target value for the payment instrument, the payment instrument is determined to be an overloaded payment instrument. The preset target value may be determined according to a capacity threshold set at the second current limiting node for each payment instrument and may be updated in real time according to a capacity change of each payment instrument.

In step 705, an idle payment instrument is recommended to the primary payment instrument for a subset of users who overload the payment instrument.

Preferably, the subset of users using the overloaded payment instrument is selected based on user usage habits and/or historical payment success rates.

At step 706, the transaction request is throttled at the second throttle node for each payment instrument.

The second throttling node (e.g., a payment link throttling node) sets a capacity threshold for each payment instrument. The capacity threshold may be dynamically adjusted based on downstream payment instrument capacity changes. The second throttling node throttles for each payment instrument, allows payment requests less than or equal to the capacity threshold of the payment instrument to pass through, enters the payment link, and payment requests exceeding the capacity threshold need to be queued. A transaction request is sent to the payment link through the second streaming node.

As shown in fig. 8, an apparatus for a payment instrument current limit method may include a receiving module 801, a first current limit module 802, a second current limit module 806, and a transmitting module 807.

The receiving module 801 may be configured to receive transaction requests from a plurality of users, the transaction requests including at least a user ID of a requested transaction.

The first current limit module 802 includes an overall current limit sub-module 803, a determination sub-module 804, and a recommendation sub-module 805.

The global throttling sub-module 803 may be configured to global throttle these transaction requests as required by the first throttling node (e.g., the cashier ring throttling node).

The determination submodule 804 may be configured to determine a number of transaction requests corresponding to each payment instrument; setting a target value of a corresponding payment instrument in the first current limiting node; and comparing the transaction request quantity of each payment instrument with a target value of the payment instrument to determine an overloaded payment instrument and an idle payment instrument.

The recommendation sub-module 805 may be configured to recommend using an idle payment instrument to a user who defaults to using an overloaded payment instrument.

The second throttling module 806 may be configured to throttle the transaction requests for each payment instrument.

The second flow restriction module 806 may be configured to set a capacity threshold for each payment instrument. The capacity threshold may be dynamically adjusted based on downstream payment instrument capacity changes. The second throttling module throttles for each payment instrument, allows payment requests less than or equal to a capacity threshold of the payment instrument to pass through, enters the payment link, and payment requests exceeding the capacity threshold need to be queued.

The transfer module 807 is configured to send a payment request through the second streaming node to the payment link.

The description set forth herein in connection with the appended drawings describes example configurations and is not intended to represent all examples that may be implemented or fall within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration," and does not mean "better than" or "over other examples. The detailed description includes specific details to provide an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.

In the drawings, similar components or features may have the same reference numerals. Further, individual components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference number is used in the specification, the description may be applied to any one of the similar components having the same first reference number regardless of the second reference number.

The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software for execution by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwired or any combination thereof. Features that implement the functions may also be physically located in various places including being distributed such that parts of the functions are implemented at different physical locations. In addition, as used herein (including in the claims), an "or" used in an item enumeration (e.g., an item enumeration accompanied by a phrase such as "at least one of" or "one or more of" indicates an inclusive enumeration, such that, for example, enumeration of at least one of A, B or C means a or B or C or AB or AC or BC or ABC (i.e., a and B and C). Also, as used herein, the phrase "based on" should not be construed as referring to a closed set of conditions. For example, exemplary steps described as "based on condition a" may be based on both condition a and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" should be read in the same manner as the phrase "based at least in part on".

Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Non-transitory storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, non-transitory computer-readable media can comprise RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact Disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk (disc) and disc (disc), as used herein, includes CD, laser disc, optical disc, digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

The description herein is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A payment control method, comprising:

recommending idle payment instruments to the main payment instrument for a subset of users of the overloaded payment instruments, the subset of users of the recommended idle payment instruments being selected according to user usage habits and/or historical payment success rates; and

throttling the transaction requests for each payment instrument at a second throttling node;

the total number of transaction requests associated with each payment instrument is compared to a preset target value for the payment instrument to determine whether the payment instrument is an idle payment instrument or an overloaded payment instrument, the preset target value being determined from a capacity threshold set for each payment instrument at the second current limit node and updated in real time according to a change in capacity of each payment instrument.

2. The method of claim 1, further comprising determining that the payment instrument is an idle payment instrument if the total number of transaction requests associated with the payment instrument is below a preset target value for the payment instrument.

3. The method of claim 1, further comprising determining that the payment instrument is an overloaded payment instrument if the total number of transaction requests associated with the payment instrument is greater than a preset target value for the payment instrument.

4. The method of claim 1, further comprising sending a transaction request through the second streaming node to a payment link.

5. A payment control device, comprising:

a first current limiting module configured to:

determining a primary payment instrument associated with each transaction request through the first streaming node based on the user's ID and determining whether the primary payment instrument is an idle payment instrument or an overloaded payment instrument, a subset of users being recommended idle payment instruments being selected based on user usage habits and/or historical payment success rates; and

recommending idle payment instruments to the master payment instrument for a subset of users of the overloaded payment instruments; and a second throttling module configured to throttle the transaction request for each payment instrument at a second throttling node;

the first current limiting module is configured to: the total number of transaction requests associated with each payment instrument is compared to a preset target value for the payment instrument to determine whether the payment instrument is an idle payment instrument or an overloaded payment instrument, the preset target value being determined from a capacity threshold set for each payment instrument at the second current limit node and updated in real time according to a change in capacity of each payment instrument.

6. The apparatus of claim 5, the first current limiting module further configured to: if the total number of transaction requests associated with a payment instrument is below a preset target value for the payment instrument, the payment instrument is determined to be an idle payment instrument.

7. The apparatus of claim 5, wherein the first current limiting module is further configured to: if the total number of transaction requests associated with a payment instrument is above a preset target value for the payment instrument, the payment instrument is determined to be an overloaded payment instrument.

8. The apparatus of claim 5, further comprising a transmission module configured to send a transaction request through the second streaming node to a payment link.

9. A payment control device, comprising:

a processor; and