A payment route allocation method, apparatus and device

Abstract

This application discloses a payment routing allocation method, apparatus, and device, relating to the field of data processing technology, aiming to solve the problem of excessive deviation between the actual number of payment transactions executed by each sub-payment channel and a preset value. The method receives a payment request and determines the payment channel set to which the payment request belongs. The payment channel set contains at least two sub-payment channels; each sub-payment channel corresponds to its own token bucket; the number of tokens in the token bucket corresponding to each sub-payment channel is proportional to a preset routing ratio; in response to the payment request, it obtains the current available token count in the token bucket corresponding to each sub-payment channel and calculates the total number of tokens; it generates a target random number within the numerical range corresponding to the total number of tokens, and determines the target sub-payment channel based on the position of the target random number within the numerical range; it decrements the token count in the token bucket corresponding to the target sub-payment channel and performs a payment routing jump based on the target sub-payment channel to complete the payment request.

Description

Technical Field

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

[0002] In high-frequency transaction scenarios such as airline ticket sales, payment systems typically employ payment channel aggregation technology to aggregate multiple sub-payment channels with the same payment attributes (such as international cards, quick payments, etc.) into a logical set, in order to provide redundancy backup and simplify user selection.

[0003] Current payment routing allocation methods have certain limitations, which makes it difficult to keep in line with the preset routing ratio of the actual number of payment transactions executed by each sub-payment channel in payment scenarios with cluster computing, resulting in difficulties in financial auditing.

[0004] Therefore, how to solve the problem of excessive deviation between the actual number of payment orders executed by each sub-payment channel and the preset value is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a payment route allocation method, apparatus, and device, which aims to solve the problem of excessive deviation between the payment route ratio and the preset value caused by the traditional random number algorithm allocation strategy.

[0006] Firstly, this application provides a payment routing allocation method applied to a payment gateway. The method includes: receiving a payment request and determining the payment channel set to which the payment request belongs, the payment channel set containing at least two sub-payment channels; each sub-payment channel corresponds to its own token bucket; the number of tokens in the token bucket corresponding to each sub-payment channel is proportional to a preset routing ratio configuration; in response to the payment request, obtaining the current available number of tokens in the token bucket corresponding to each sub-payment channel and calculating the total number of tokens; generating a target random number within a numerical range corresponding to the total number of tokens, and determining the target sub-payment channel based on the position of the target random number within the numerical range; performing a token decrement operation on the token bucket corresponding to the target sub-payment channel, and performing a payment routing jump based on the target sub-payment channel to complete the payment request.

[0007] The payment routing allocation method provided in this application configures the number of tokens in the token bucket corresponding to each sub-payment channel to be proportional to a preset routing ratio, so that the number of available tokens in each token bucket is dynamically mapped to the weight ratio of the channel. In response to a payment request, the method obtains the current number of available tokens in each token bucket and calculates the total number of tokens. A target random number is generated within the numerical range corresponding to the total number of tokens, and the target sub-payment channel is determined based on the position of the target random number within the numerical range. The token count corresponding to the target sub-payment channel is decremented by one, and the user is redirected to that target sub-payment channel.

[0008] Compared to traditional random number algorithm allocation methods, this application uses a payment routing allocation method based on the token bucket algorithm. By utilizing the probability distribution characteristics of random numbers falling into different token bucket value ranges, the accuracy of payment routing can be improved, ensuring that the actual probability of each channel being selected conforms to the preset routing ratio configuration. This solves the problem of excessive deviation between the payment routing ratio and the preset value.

[0009] In one possible implementation, the target sub-payment channel is determined based on the position of the target random number in the numerical range, including: during the i-th traversal, obtaining the number of available tokens for the candidate sub-payment channel in the current traversal; determining whether the target random number is less than the number of available tokens; if it is less, then determining the candidate sub-payment channel as the target sub-payment channel; otherwise, using the difference between the target random number and the number of available tokens as the target random number in the next traversal, and repeating the above process.

[0010] In one possible implementation, the numerical range includes sub-numerical ranges corresponding to each sub-payment channel; determining the target sub-payment channel based on the position of the target random number within the numerical range includes: determining the target sub-payment channel based on the sub-numerical range into which the target random number falls.

[0011] In one possible implementation, before obtaining the current number of available tokens in the token bucket corresponding to each sub-payment channel, a first token lock is configured for the token bucket corresponding to each sub-payment channel; after calculating the total number of tokens, the first token lock is released; before performing a token decrement operation on the token bucket corresponding to the target sub-payment channel, a second token lock is configured for the token bucket corresponding to each sub-payment channel; after performing a token decrement operation on the token bucket corresponding to the target sub-payment channel, the second token lock is released.

[0012] In one possible implementation, the actual number of payment orders for each sub-payment channel within a preset period is counted; based on a preset calibration algorithm formula, the routing ratio configuration is dynamically adjusted according to the actual number of supported orders.

[0013] In one possible implementation, the routing ratio configuration includes the routing ratio corresponding to each sub-payment channel; the preset calibration algorithm formula is determined according to the following expression: Dynamically adjusted routing ratio of sub-payment channel = (routing ratio) 2) - (Actual number of payment orders in sub-payment channels / Total number of payment orders in channels).

[0014] In one possible implementation, after determining the payment channel set to which the payment request belongs, the method further includes: if there is no corresponding token bucket in the payment channel set, and if there is a dynamically adjusted routing ratio configuration, then the token quota corresponding to each sub-payment channel is obtained based on the dynamically adjusted routing ratio configuration to construct the token bucket; if there is no dynamically adjusted routing ratio configuration, then the token quota corresponding to each sub-payment channel is constructed based on the preset routing ratio configuration.

[0015] In one possible implementation, a switching instruction is received; the switching instruction is used to indicate the sub-payment channel to be switched among at least two sub-payment channels; according to the preset allocation weight, the original routing ratio of the sub-payment channel to be switched is allocated to other sub-payment channels, and the routing ratio of the sub-payment channel to be switched is set to 0, thereby generating a dynamically adjusted routing ratio configuration.

[0016] Secondly, this application provides a payment routing ratio allocation device, which includes: an acquisition module, a determination module, and an operation module; the determination module is used to receive a payment request and determine the payment channel set to which the payment request belongs, the payment channel set including at least two sub-payment channels; different sub-payment channels correspond to their respective token buckets; the number of tokens in the token buckets corresponding to each sub-payment channel is proportional to a preset routing ratio configuration; the acquisition module is used to, in response to the payment request, acquire the current available number of tokens in the token buckets corresponding to each sub-payment channel and calculate the total number of tokens; the determination module is also used to generate a target random number within the numerical range corresponding to the total number of tokens, and determine the target sub-payment channel based on the position of the target random number in the numerical range; the operation module is used to perform a token decrement operation on the token bucket corresponding to the target sub-payment channel, and perform a payment routing jump based on the target sub-payment channel to complete the payment request.

[0017] In one possible implementation, the determining module is specifically used to determine the target sub-payment channel based on the position of the target random number in the numerical range, including: during the i-th traversal, obtaining the number of available tokens for the candidate sub-payment channel in the current traversal; determining whether the target random number is less than the number of available tokens; if it is less, determining the candidate sub-payment channel as the target sub-payment channel; otherwise, using the difference between the target random number and the number of available tokens as the target random number in the next traversal, and repeating the above process.

[0018] In one possible implementation, the operation module is further configured to: configure a first token lock on the token bucket corresponding to each sub-payment channel before obtaining the current number of available tokens in the token bucket corresponding to each sub-payment channel; release the first token lock after calculating the total number of tokens; configure a second token lock on the token bucket corresponding to each sub-payment channel before performing a token decrement operation on the token bucket corresponding to the target sub-payment channel; and release the second token lock after performing a token decrement operation on the token bucket corresponding to the target sub-payment channel.

[0019] In one possible implementation, the determining module is also used to count the actual number of payment orders for each sub-payment channel within a preset period; and to dynamically adjust the routing ratio configuration based on the actual number of supported orders according to a preset calibration algorithm formula.

[0020] In one possible implementation, the determination module is specifically used to determine the preset calibration algorithm formula according to the following expression: Dynamically adjusted routing ratio of sub-payment channels = (Route ratio) 2) - (Actual number of payment orders in sub-payment channels / Total number of payment orders in channels).

[0021] In one possible implementation, the determining module is further configured to, after determining the payment channel set to which the payment request belongs, further include: if there is no corresponding token bucket in the payment channel set, if there is a dynamically adjusted routing ratio configuration, then obtain the token quota corresponding to each sub-payment channel based on the dynamically adjusted routing ratio configuration to construct the token bucket; if there is no dynamically adjusted routing ratio configuration, then construct the token bucket based on the token quota corresponding to each sub-payment channel based on the preset routing ratio configuration.

[0022] In one possible implementation, the determining module is further configured to: receive a switching instruction; the switching instruction is used to indicate the sub-payment channel to be switched among at least two sub-payment channels; according to a preset allocation weight, allocate the original routing ratio of the sub-payment channel to be switched to other sub-payment channels, and set the routing ratio of the sub-payment channel to be switched to 0, thereby generating a dynamically adjusted routing ratio configuration.

[0023] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect described above.

[0024] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0025] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0026] The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

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

[0028] Figure 1 A schematic diagram of a payment routing allocation system provided in this application embodiment; Figure 2 A software module diagram provided for an embodiment of this application; Figure 3 This is a schematic flowchart of a payment routing allocation method provided in an embodiment of this application; Figure 4 This application provides a schematic diagram of a process for determining a target sub-payment channel in an embodiment of the present application. Figure 5 A flowchart illustrating token consumption and payment channel allocation is provided for an embodiment of this application. Figure 6 A flowchart of dynamic routing ratio adjustment provided in this application embodiment; Figure 7 A token bucket replenishment flowchart is provided for embodiments of this application; Figure 8 A software platform flowchart provided for an embodiment of this application; Figure 9 An overall flowchart provided for an embodiment of this application; Figure 10 This is a schematic diagram of a routing ratio configuration adjustment process provided in an embodiment of this application; Figure 11 This application provides a schematic diagram of a dynamic routing adjustment process. Figure 12 A schematic diagram of a payment routing allocation device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the composition of a computing device provided in an embodiment of this application. Detailed Implementation

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] In the description of this application, it should be understood that the terms "upper," "lower," "left," "right," "front," "rear," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or relative positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and for simplification, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Unless otherwise specified, the above-mentioned orientational descriptions can be flexibly set in practical applications, provided that the relative positional relationships shown in the accompanying drawings are satisfied.

[0031] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0032] As described in the background section above, in the fields of aviation tourism and e-commerce payment information technology, payment channel sets, as a collection solution integrating multiple payment channels (such as international card payments, quick payments, etc.), are widely used to improve payment success rates and optimize user experience. When faced with scenarios where a single payment channel becomes unavailable due to payment merchant system anomalies or network instability, the payment system typically uses a preset routing ratio strategy to distribute transaction traffic to different sub-payment channels within the payment channel set, thereby achieving load balancing and fault avoidance.

[0033] Existing technologies balance the load and traffic of each payment channel in a large-scale cluster environment by allocating the call ratio of each sub-payment channel. However, this makes it difficult to ensure that the actual number of payment transactions executed by each sub-payment channel is consistent with the preset routing ratio. Some sub-payment channels may be overloaded, while others may be restricted, which will have a negative impact on merchant operations, financial auditing, cost, and passenger payment experience.

[0034] Based on this, the payment routing allocation method provided in this application configures the number of tokens in the token bucket corresponding to each sub-payment channel to be proportional to a preset routing ratio, so that the number of available tokens in each token bucket is dynamically mapped to the weight ratio of the channel. In response to a payment request, the current number of available tokens in each token bucket is obtained and the total number of tokens is calculated. A target random number is generated within the numerical range corresponding to the total number of tokens, and the target sub-payment channel is determined based on the position of the target random number within the numerical range. The token count of the tokens corresponding to the target sub-payment channel is decremented by one, and the user is redirected to that target sub-payment channel.

[0035] Compared to traditional random number algorithm allocation methods, this application uses a payment routing allocation method based on the token bucket algorithm. By utilizing the probability distribution characteristics of random numbers falling into different token bucket value ranges, the accuracy of payment routing can be improved, ensuring that the actual probability of each channel being selected conforms to the preset routing ratio configuration. This solves the problem of excessive deviation between the payment routing ratio and the preset value.

[0036] This application provides a payment routing allocation system based on the token bucket algorithm. Figure 1 This is a schematic diagram of a payment routing allocation system provided in an embodiment of this application, such as... Figure 1 As shown, the payment routing allocation system 100 is physically composed of a payment gateway 11, a payment institution device 12, and a user terminal 13 connected via a communication network. The payment gateway 11, as the core execution entity of this application, is deployed in a data center or cloud and is responsible for handling high-concurrency payment routing allocation tasks. The payment institution device 12 serves as an external interaction device, used to complete the final payment transaction. The user terminal 13, as the business initiator, is used to initiate payment requests.

[0037] The payment gateway 11 comprises a processor, memory, a network interface, and a system bus. The processor (such as a multi-core CPU or a dedicated acceleration chip) is configured to execute computer instructions stored in memory to receive payment requests, perform logical operations on the token bucket algorithm, schedule the locking mechanism, and control routing jumps. The memory includes high-speed volatile memory (such as DRAM) and non-volatile memory (such as SSDs or hard disks). The volatile memory is used to cache in real-time the token bucket data structure corresponding to each sub-payment channel, the status flags of the first and second token locks, and the target random number and total token quantity generated during the calculation process, ensuring high-concurrency security for data read and write operations. The non-volatile memory is used to persistently store the routing ratio configuration table, the payment channel set table, historical payment transaction statistics records, and the operating system and application code. The network interface (such as a gigabit or 10-gigabit network card) is used to establish data communication connections with the payment institution's equipment 12 and the user terminal 13 via a financial leased line or the Internet.

[0038] Payment institution device 12 can be a transaction server of a third-party banking system or payment gateway, connected to the payment server via a network interface. After the payment server's processor determines the target sub-payment channel based on the token bucket algorithm, it constructs a transaction message containing specific payment instructions and sends it to the corresponding payment institution device via the network interface. The payment institution device's processor processes the transaction and returns a payment result (success or failure). This result data is transmitted back to the payment server via the network for subsequent statistical updates or anomaly handling by the payment server's processor.

[0039] User terminal 13 may include a smartphone, tablet, or personal computer, and integrates a display module, a touch / input module, a processor, and a wireless / wired network module. In a payment scenario, the processor of user terminal 13 controls the display module to show the cashier page, and receives the user's selection of payment method through the touch / input module. After the user confirms the payment, the network module of user terminal 13 sends a payment request data packet to payment gateway 11 via the Internet. This data packet contains order information, payment method identifier, etc., and is received by the network interface of payment gateway 11 and handed over to the processor for subsequent routing and allocation processing.

[0040] During the operation of this system, the various hardware devices work together to form a closed loop: User terminal 13 initiates a payment request through the network interface, and payment gateway 11 responds to the payment request. The processor of payment gateway 11 begins to read the token bucket data in the memory, reads the number of available tokens by configuring the first token lock and calculates the total number of tokens, generates a target random number and determines the target sub-payment channel; subsequently, the processor configures the second token lock to perform a token decrement operation and controls the network interface to forward the payment request to the payment institution's equipment; at the same time, payment gateway 11 performs payment monitoring. The processor of payment gateway 11 checks the actual payment status of each target sub-payment channel according to instructions. The processor adjusts the routing ratio configuration by executing a dynamic calibration algorithm, thereby ensuring that the token bucket data of each sub-payment channel is consistent with the preset ratio, and achieving accurate and efficient payment routing allocation.

[0041] The above describes the hardware architecture used in the method provided in this application. Figure 2 A software module diagram provided for an embodiment of this application, such as Figure 2 As shown, the user terminal module can be applied to the above-mentioned... Figure 1 In user terminal 13, customers select items, place orders, and initiate payment requests through the user terminal module. The cashier module, payment application cluster module, and payment monitoring module are deployed in the aforementioned... Figure 1In the payment gateway 11, the cashier module receives the payment request sent by the user terminal module and sends it to the payment application cluster module in the payment gateway. The payment application cluster module contains the channel set routing ratio and corresponding token bucket of payment application node one, the channel set routing ratio and corresponding token bucket of payment application node two, and the channel set routing ratio and corresponding token bucket of payment application node three. The payment application cluster module is connected to the payment merchant module, which includes payment merchant A, payment merchant B, etc. The payment merchant module is used for the above... Figure 1 The payment institution interface is 12. The payment monitoring module connects to the channel set routing ratio and token bucket in the payment channel set module. The payment monitoring module monitors payment anomaly indicators, detects the channel set routing ratio, and dynamically switches the routing ratio and resets the token bucket. The payment monitoring module also performs token bucket number calibration and optimization, and replenishes the token bucket.

[0042] Figure 3 This is a schematic flowchart illustrating a payment routing allocation method provided in an embodiment of this application. For example, the payment routing allocation method provided in this embodiment can be applied to... Figure 1 Specifically, in the payment gateway 11 shown, the method can be executed by the processor of the payment gateway 11.

[0043] like Figure 3 As shown, the payment routing allocation method provided in this application embodiment may include the following steps: S301. Receive a payment request and determine the payment channel set to which the payment request belongs.

[0044] The payment channel set includes at least two sub-payment channels, each with its own token bucket. The number of tokens in the token bucket of each sub-payment channel is proportional to the preset routing ratio configuration.

[0045] As is understandable, a payment request is a data interaction instruction initiated by the user terminal to the payment gateway, which includes order information and payment method selection identifier. Its core function is to trigger the payment gateway to start subsequent payment routing allocation.

[0046] A payment channel set refers to a logical collection of at least two sub-payment channels, each of which is an independent channel executing a specific payment transaction. For example, a payment channel set for international card payments might include sub-payment channels such as Visa, Mastercard, and UnionPay International. Within the payment channel set, each sub-payment channel corresponds to an independent token bucket. A token is a data structure used to limit or control the rate of request access. The token quantity refers to the number of resource units currently available for allocation in the token bucket. Its value is directly determined by a preset routing ratio configuration; that is, the initial or current token quantity in the token bucket is proportional to the number of tokens available for allocation.

[0047] In one implementation, after receiving a payment request through the network interface, the payment gateway's processor immediately parses the request, determines the target payment channel set, reads the preset routing ratio configuration, determines the number of tokens stored in each token bucket, and ensures that the resource quota of each sub-payment channel strictly follows the preset ratio.

[0048] For example, when the payment gateway determines the target payment channel set, which includes payment channel A and payment channel B, and the proportions of the sub-payment channels in the preset routing ratio configuration are 0.6 and 0.4 respectively, the processor of the payment gateway will calculate and set the number of tokens in the corresponding token bucket to 600 and 400 respectively.

[0049] S302. In response to the payment request, obtain the number of available tokens in the token bucket corresponding to each sub-payment channel, and calculate the total number of tokens.

[0050] The available token quantity refers to the remaining amount of tokens in the current token bucket that have not been consumed and can be allocated for this payment request; the total token quantity refers to the arithmetic sum of the available token quantities of all sub-payment channels under the current payment channel set.

[0051] In this embodiment of the application, the payment gateway responds to a payment request from a user terminal and obtains the number of available tokens in the token bucket corresponding to the sub-payment channel based on the payment request.

[0052] S303. Generate a target random number within the numerical range corresponding to the total number of tokens, and determine the target sub-payment channel based on the position of the target random number within the numerical range.

[0053] As can be understood, the numerical range refers to a continuous range of integers from 0 (or 1, depending on the specific implementation) to the total number of tokens (or the total number of tokens minus 1). The target random number is a random integer value generated by the payment gateway's processor within the aforementioned numerical range using a random number generation algorithm. The target sub-payment channel refers to the target sub-payment channel determined by the payment gateway based on the distribution of the target random number within the aforementioned numerical range, according to a preset calculation method.

[0054] As one possible implementation, Figure 4 This application provides a schematic diagram of a process for determining a target sub-payment channel, as illustrated in the embodiments below. Figure 4 As shown, in step S303 above, determining the target sub-payment channel based on the position of the target random number within the numerical range can be specifically implemented as follows: S3031. During the i-th traversal, obtain the number of available tokens for the candidate sub-payment channels being traversed.

[0055] The traversal process refers to the payment gateway visiting all the sub-payment channels in the currently selected payment channel set in a certain order. The candidate sub-payment channel is the one currently being traversed. In each traversal, the payment gateway accesses the corresponding token bucket to obtain the number of available tokens for the currently traversed sub-payment channel.

[0056] For example, the payment gateway obtains a payment channel set containing channel A, channel B, and channel C. During the first traversal, it obtains the number of available tokens for channel A, and during the second traversal, it obtains the number of available tokens for channel B.

[0057] S3032. Determine whether the target random number is less than the number of available tokens.

[0058] Understandably, based on the target random number obtained in step S303 above, the comparison between the target random number and the number of available tokens for the currently traversed sub-payment channels is determined. The core of this determination process is to ascertain whether the current target random number falls within the numerical range corresponding to the current candidate sub-payment channel.

[0059] In some implementations, the result of the judgment determines the direction of the subsequent process: if the judgment result is yes (i.e., the target random number is less than the number of available tokens), the process jumps to step S3033 below; if the judgment result is no, the process jumps to step S3034 below.

[0060] S3033. If it is less than, then the candidate sub-payment channel is determined as the target sub-payment channel.

[0061] S3034. Otherwise, use the difference between the target random number and the number of available tokens as the target random number for the next traversal and repeat the above process.

[0062] The next traversal process refers to a new round of checks when traversing into the sub-payment channel with index i+1; repeating the above process means that the payment gateway continues to execute the loop steps of obtaining the number of available tokens for the current sub-payment channel, judging the size, and determining or updating the random number, until the target sub-payment channel is found or the traversal ends.

[0063] For example, the payment channel set determined by the payment gateway includes sub-payment channel A, sub-payment channel B, and sub-payment channel C, with a preset ratio of 20% for sub-payment channel A, 10% for sub-payment channel B, and 70% for sub-payment channel C. Assuming 1000 tokens are added at once, sub-payment channel A will receive 200 tokens, sub-payment channel B will receive 100 tokens, and sub-payment channel C will receive 700 tokens. The payment gateway determines a target random number of 850 based on the total number of tokens. First, the target random number is the tokens from sub-payment channel A. Comparing the number 200, it is determined that 850 > 200. Therefore, the target random number is modified, resulting in a new target random number of 850 - 200 = 650. The new target random number is then compared with the token count of sub-payment channel B, 300. It is determined that 650 > 100. Therefore, the target random number is modified, resulting in a new target random number of 650 - 100 = 550. The new target random number is then compared with the token count of sub-payment channel B, 700. It is determined that 550 < 700. Therefore, sub-payment channel C is determined as the target sub-payment channel.

[0064] As another feasible implementation method, the numerical range includes the sub-numerical ranges corresponding to each sub-payment channel. The target sub-payment channel is determined according to the position of the target random number in the numerical range, including: determining the target sub-payment channel according to the sub-numerical range in which the target random number falls.

[0065] Understandably, a numerical range refers to a continuous range of integers defined by the total number of tokens, while a sub-numerical range refers to a non-overlapping sub-range within the numerical range, divided according to the number of available tokens for each sub-payment channel. Determining the target sub-payment channel involves mapping the target random number to the corresponding sub-payment channel by comparing it with the boundary values ​​of the sub-numerical ranges.

[0066] For example, if the payment channel set includes "Channel A" and "Channel B", with available tokens of 100 and 50 respectively, the total number of tokens is 150, with a value range of [0, 149]. In this case, the sub-value range corresponding to "Channel A" is [0, 99], and the sub-value range corresponding to "Channel B" is [100, 149]. If the target random number generated by the processor is 85, since 85 is within the range of [0, 99], it falls within the sub-value range of "Channel A", and the payment gateway then determines "Channel A" as the target sub-payment channel. If the target random number is 120, it falls within the sub-value range of "Channel B", thus determining "Channel B" as the target sub-payment channel.

[0067] S304. Decrement the token by one in the token bucket corresponding to the target sub-payment channel, and perform a payment route redirection based on the target sub-payment channel to complete the payment request.

[0068] Understandably, payment routing refers to the payment gateway forwarding the data stream of the payment request to a specific target sub-payment channel, identifying the target payment institution, and initiating the actual payment transaction. Completing the payment request means sending a payment instruction to the target payment institution through the aforementioned routing and transaction processing, and accepting the payment result from the payment institution for verification.

[0069] This application provides a payment routing allocation method that configures the number of tokens in the token bucket corresponding to each sub-payment channel to be proportional to a preset routing ratio, so that the number of available tokens in each token bucket is dynamically mapped to the weight ratio of the channel. In response to a payment request, the method obtains the current number of available tokens in each token bucket and calculates the total number of tokens. A target random number is generated within the numerical range corresponding to the total number of tokens, and the target sub-payment channel is determined based on the position of the target random number within the numerical range. The token count corresponding to the target sub-payment channel is decremented by one, and the user is redirected to that target sub-payment channel.

[0070] Compared to traditional random number algorithm allocation methods, this application uses a payment routing allocation method based on the token bucket algorithm. By utilizing the probability distribution characteristics of random numbers falling into different token bucket value ranges, the accuracy of payment routing can be improved, ensuring that the actual probability of each channel being selected conforms to the preset routing ratio configuration. This solves the problem of excessive deviation between the payment routing ratio and the preset value.

[0071] In some embodiments, in high-concurrency payment scenarios, when multiple requests attempt to read the number of tokens or perform token deduction operations simultaneously, the lack of an effective concurrency control mechanism can easily lead to resource contention between multiple processes, resulting in inconsistent token data or over-issuance, which in turn causes payment routing allocation failure.

[0072] Based on this, in this embodiment, the above steps S301 to S304 can also be specifically implemented as follows: Step a1: Before obtaining the current number of available tokens in the token bucket corresponding to each sub-payment channel, configure the first token lock for the token bucket corresponding to each sub-payment channel; after calculating the total number of tokens, release the first token lock.

[0073] Understandably, the first token lock refers to a mutual exclusion access mechanism applied to the token buckets corresponding to each sub-payment channel in the target payment channel set to prevent data conflicts when multiple payment gateway nodes concurrently read the token count of sub-payment channels. The lock targets each token bucket instance grouped by available sub-channel identifiers. Its function is to exclusively possess the token count data of the token bucket during the read operation, avoiding data inconsistency caused by consumption or replenishment operations of other threads during the read process.

[0074] In some implementations, before the payment gateway responds to a payment request and obtains the number of available tokens in the token bucket corresponding to each sub-payment channel, it first needs to acquire the allocation payment channel token lock to prevent other parallel operations from modifying the token count for that payment channel and to avoid inconsistencies in the token count read before and after. After calculating the total number of tokens for that payment channel, the payment gateway releases the allocation payment channel token lock, allowing other parallel operations to access or modify the token count in the sub-channel token bucket.

[0075] For example, after the payment gateway successfully acquires the first token lock, it sequentially reads the number of currently available tokens in the token bucket of each sub-payment channel and encapsulates these values ​​into a hash set. The hash set records the identifier of each sub-channel and its corresponding instantaneous token quantity. After the hash set is encapsulated, the payment gateway immediately releases the first token lock.

[0076] Step a2: Before performing the token decrement operation on the token bucket corresponding to the payment channel, configure a second token lock on the token bucket corresponding to each sub-payment channel; after performing the token decrement operation on the token bucket corresponding to the target sub-payment channel, release the second token lock.

[0077] Understandably, the second token lock refers to another mutual exclusion mechanism applied before the token consumption operation is performed on the token bucket corresponding to the selected target sub-payment channel, to ensure that the token deduction action is not affected. This lock is used to protect the token value change process, preventing other threads from reading or deducting again before the deduction operation is completed, thereby ensuring that the token consumption of each sub-payment channel is strictly consistent with the actual payment transaction volume, avoiding overpayment or incorrect token count.

[0078] For example, suppose the target sub-payment channel's token bucket currently has 10 remaining tokens. When the first payment request performs a decrement operation, a second token lock is configured to lock the bucket. After the decrement, the remaining tokens are 9, and the lock is released. If a second request attempts to access the same bucket, it must wait for the lock to be released. If the second request acquires the lock after the first request releases it, the value it reads is 9. After performing the decrement again, the remaining tokens are 8.

[0079] Figure 5 This is a flowchart illustrating token consumption and payment channel allocation as provided in an embodiment of this application. Figure 5 As shown, the payment gateway enters the process of consuming tokens to obtain a payment channel. First, it determines the number of sub-channels in the channel set to see if only one usable sub-channel exists. If the result is yes, the method provided in this embodiment is not used; instead, the gateway directly checks if the target channel's token bucket is empty. If the target channel is empty, the gateway returns to the target payment channel and ends the process. If the target channel's token count is not empty, the payment gateway acquires a consumption token lock, consumes the target channel's token count, releases the consumption token lock, returns to the target payment channel, and ends the process.

[0080] If two or more available sub-channels exist, the result is negative. The payment gateway acquires the first token lock (the sub-channel allocation lock), obtains the available token count for each available sub-channel based on its identifier, releases the sub-channel allocation lock, calculates the total number of tokens for all available sub-channels, and obtains a random number within the total token count range. The payment gateway iterates through the available sub-channels, obtains the available token count for the currently iterated sub-payment channel, and checks if a next element exists. If it does, it means the channel set has not been completely traversed. It then checks if the random number is less than the current sub-channel's token count. If the result is yes, it determines the target payment channel and exits the loop. It then checks if the target payment channel is empty. If the target channel is empty, it returns to the target payment channel and ends the process. If the target channel is not empty, it acquires the second token lock (the consumption token lock), decrements the token count in the target channel's token bucket by one, releases the consumption token lock, returns to the target payment channel, and ends the process. If the target random number is not less than the current sub-channel's token count (i.e., the result is negative), it subtracts the current sub-channel's available token count from the random number and re-enters the check for a next element.

[0081] If the payment gateway determines whether the next element exists and the result is negative, it means that the channel set has been completely traversed. It then directly checks if the target channel is empty. If the target channel is empty, it returns to the target payment channel and ends the process. If the target channel is not empty, it acquires a consumption token lock, decrements the token count in the target channel's token bucket by one, releases the consumption token lock, returns to the target payment channel, and ends the process.

[0082] This embodiment offers the following advantages: by configuring a first token lock and a second token lock in the key steps of reading and consuming tokens respectively, the token buckets of each sub-channel are locked during the calculation of the total number of tokens, ensuring that multiple concurrent requests cannot interfere with data consistency within the current calculation cycle. Furthermore, locking is applied again when performing the token deduction operation to prevent duplicate token consumption or negative value anomalies that may occur in a multi-threaded environment. In this way, this embodiment can eliminate the risk of data inconsistency in high-concurrency scenarios during cluster deployment.

[0083] In some embodiments, since the carrying capacity, response speed and success rate of payment channels fluctuate dynamically with business hours, if routing is allocated based solely on a preset static ratio, it is easy to cause congestion in some high-load channels or idle resources in low-load channels, thereby reducing the overall payment success rate and system resource utilization.

[0084] Based on this, as a feasible implementation method, its specific implementation includes the following steps: Step b1: Calculate the actual number of payment orders for each sub-payment channel within the preset period.

[0085] Understandably, the preset period refers to the time interval at which the system automatically performs the route ratio calibration task. This period can be configured as a day, week, month, or a specific hourly unit to define the scope of statistical historical payment data.

[0086] In some implementations, the payment gateway first queries the corresponding payment routing configuration based on the configuration information. The payment routing configuration contains at least one payment channel set. The payment gateway obtains the corresponding payment channel set information based on the parameters of the specified payment channel set to be obtained. The payment gateway traverses each sub-payment channel in the payment channel set, counts the actual payment order volume of each sub-payment channel within a preset period, and then calculates the number of payment orders for each sub-payment channel in the current month.

[0087] Step b2: Based on the preset calibration algorithm formula, dynamically adjust the routing ratio configuration according to the actual number of supported units.

[0088] The preset calibration algorithm formula refers to a specific mathematical model used to calculate the dynamic adjustment of the routing ratio. This model calculates the compensation value or adjustment value by comparing the actual payment ratio of the sub-payment channel with the preset routing configuration ratio, so as to correct the routing ratio imbalance caused by random number algorithm deviation or traffic fluctuation.

[0089] As a feasible implementation method, the routing ratio configuration includes the routing ratio corresponding to each sub-payment channel. The preset calibration algorithm formula is determined according to the following expression: Dynamically adjusted routing ratio of sub-payment channels = (routing ratio) 2) - (Actual number of payment orders in sub-payment channels / Total number of payment orders in channels).

[0090] The payment gateway queries the routing ratio adjustment configuration. If the payment gateway detects that the above-mentioned periodic routing adjustment task has been executed, the payment gateway will subsequently start executing the dynamic routing ratio adjustment task.

[0091] For example, Figure 6 This document provides a flowchart for a dynamic routing ratio adjustment method as described in an embodiment of this application. Figure 6 As shown, the payment gateway enters the dynamic token bucket adjustment ratio calculation process, calculates the monthly payment volume of the channel set, first sets i=0, size=number of sub-payment channels, and then checks if i < size. If the result is yes, it means the process is not complete. The payment gateway calculates the proportion of sub-channel payment orders to the total number of channel sets in the current month, and calculates the adjusted routing ratio according to the formula: Dynamically adjusted routing ratio of sub-payment channels = (routing ratio) 2) Actual payment volume of sub-payment channels / Total payment volume of channels. This will determine if the adjustment ratio is less than the minimum guarantee ratio. The minimum guarantee ratio is calculated as follows: Minimum Guarantee Ratio = Original Ratio The minimum guarantee factor is determined by whether it is configured by the operator in the backend. If the result is yes, the minimum guarantee routing ratio is calculated, rounded up, and adjusted to the minimum guarantee ratio. The sub-channel's routing ratio is also modified to the adjusted ratio. If the result is no, the sub-channel's routing ratio is directly modified to the adjusted ratio. The payment gateway is added to the adjustment ratio set and iterated through, performing an i+1 operation. When i is less than size (indicating no), the payment gateway returns the adjusted routing ratio set, and the process ends.

[0092] This embodiment can provide the following beneficial effects: by introducing a periodic statistical analysis of actual payment transactions and a dynamic calibration mechanism based on a specific formula, the payment gateway can automatically identify and quantify the traffic deviation of each sub-channel within a preset period, thereby generating a corrected routing ratio that can correct historical deviations.

[0093] In some embodiments, when a configuration change results in a lack of a corresponding token bucket in the payment channel set, if automatic initialization cannot be completed, the system will be unable to effectively control traffic and route requests to that channel set. Therefore, as a feasible implementation, after determining the payment channel set to which the payment request belongs, the method further includes: If there is no corresponding token bucket in the payment channel set, but there is a dynamically adjusted routing ratio configuration, then the token quota corresponding to each sub-payment channel is obtained based on the dynamically adjusted routing ratio configuration in order to construct the token bucket.

[0094] Understandably, the dynamically adjusted routing ratio configuration refers to the latest routing ratio parameter written into the "Dynamic Routing Adjustment Table" after the system has undergone periodic calibration or real-time dynamic switching. This parameter is used to correct the original preset ratio to reflect the real-time business load and channel health status.

[0095] In some implementations, after the payment gateway receives a payment request and determines its payment channel set, it first checks whether an initialized token bucket instance exists in memory for that payment channel set. If the check finds no corresponding token bucket, the payment gateway proceeds to the configuration reading phase. First, it queries the "Dynamic Route Adjustment Table" to determine if a dynamically adjusted route ratio configuration exists for that payment channel set. If it does, the payment gateway prioritizes reading the "Adjusted Route Ratio" field recorded in the table, using this dynamically adjusted route ratio as the basis for calculation to determine the initial token quota for each sub-payment channel. Then, based on this quota, it initializes and constructs a token bucket, ensuring that the token distribution within the token bucket immediately matches the latest business strategy.

[0096] If there is no dynamically adjusted routing ratio configuration, the token quota for each sub-payment channel is configured based on the preset routing ratio to build a token bucket.

[0097] When there is no dynamically adjusted routing ratio configuration, the preset routing ratio configuration serves as a fallback solution to generate the initial token quota for each sub-payment channel, ensuring that the payment gateway can allocate routes according to the established strategy without special intervention.

[0098] In some implementations, the specific method for constructing a token bucket based on a preset routing ratio configuration is as follows: When the payment gateway detects that there is no corresponding record in the "Dynamic Routing Adjustment Table" or that the dynamic configuration it reads is empty, it queries the "Payment Channel Routing Ratio Configuration Table." The payment gateway extracts the routing ratio data of each sub-payment channel associated with the current payment channel set from this table and uses it as the basic weight for calculating the token quota. Subsequently, the payment gateway combines the "supplementary token base" configured by the system (i.e., the total amount of tokens replenished at one time), multiplies the preset ratio by the base, calculates the initial number of tokens that each sub-payment channel should obtain, and uses this to construct a brand new token bucket instance, completing the initialization process.

[0099] For example, Figure 7 A token bucket replenishment flowchart is provided for embodiments of this application. For example... Figure 7As shown, the payment gateway enters the token replenishment process. First, it reads the dynamic routing configuration information, queries the dynamic routing adjustment table, reads the dynamic routing adjustment ratio, and then checks if the dynamic routing configuration information exists. If not, it reads the routing configuration ratio, queries the routing ratio configuration table, and calculates the replenishment token count, which is equal to the replenishment base. The routing ratio is determined, and the payment gateway replenishes the token bucket, ending the process. If the determination is correct, the replenished token count is directly calculated, the token bucket is replenished, and the process ends.

[0100] This embodiment provides the following beneficial effects: during token bucket initialization, it prioritizes reading the dynamically adjusted routing ratio configuration; if not found, it falls back to the preset hierarchical acquisition strategy. This method ensures that the token bucket possesses adaptive correction capabilities from the initialization stage, improving the timeliness and accuracy of the new request allocation strategy.

[0101] In some embodiments, if a specific sub-payment channel fails or requires temporary maintenance, and its traffic cannot be smoothly transferred to other available channels quickly, it will cause a backlog of requests or direct failures on that channel, severely impacting the overall payment success rate and user experience.

[0102] Based on this, in this embodiment, a switching instruction is received to indicate the sub-payment channel to be switched, and the original routing ratio of the sub-payment channel to be switched is redistributed to other sub-payment channels according to the preset allocation weight. At the same time, the routing ratio of the sub-payment channel to be switched is set to 0, thereby generating a dynamically adjusted routing ratio configuration to achieve real-time isolation of faulty channels and redistribution of traffic.

[0103] Understandably, the payment gateway will receive a switching instruction after reaching the threshold configured in the management backend terminal. This threshold is reached when the actual payment ratio of a sub-payment channel in the payment channel set differs significantly from the preset payment ratio. The allocation weight refers to the weight of each sub-payment channel configured in the management backend terminal. This weight indicates the priority for merging the payment ratios of a sub-payment channel after it reaches the threshold.

[0104] As one possible implementation, the payment gateway dynamically calculates the routing ratio of each channel in real time. Once the threshold for dynamically adjusting the routing ratio configuration is reached, the payment routing ratio of sub-payment channels that exceed the threshold is set to 0.

[0105] If the backend terminal is configured with payment channel weights, a target payment channel is matched according to the weights. This target payment channel is used to merge the payment ratios of the sub-payment channels that exceed the threshold. The payment routing ratio of this target payment channel is dynamically changed to: Target channel payment ratio = Target channel payment ratio + Original channel payment routing ratio.

[0106] If the backend terminal does not configure payment channel weights, the payment gateway queries all sub-channels of the payment channel set, then uses average allocation to assign an equal payment routing ratio to each sub-channel, then updates the routing ratios and sends relevant alarm notifications.

[0107] For example, as given above, the payment channel weights configured for channels A, B, and C are 0.5, 0.4, and 0.3, respectively, and the payment ratios for channels A, B, and C are 10%, 50%, and 40%, respectively. After channel A exceeds the threshold, the payment ratio for channel A is adjusted from the original 10% to 0. Based on the weight matching, another target payment channel is determined as channel B. Then, the final payment ratio for channel B is 50% + 10% = 60%.

[0108] This embodiment can provide the following beneficial effects: it avoids the risk of order payment interruption caused by the abnormality of a single payment merchant and improves the fault tolerance of the payment system.

[0109] The above is a detailed description of the payment routing allocation method provided in the embodiments of this application. Figure 8 A software platform flowchart is provided for an embodiment of this application, such as... Figure 8 As shown, the user first places an order and makes a payment request, which enters the payment system. This payment system integrates the functions of the aforementioned payment gateway. Based on a token bucket algorithm-based routing ratio allocation model, the payment system determines the payment channel. The payment system then allocates payment tokens and resets / replenishes the token bucket. Specifically, it allocates payment tokens to the corresponding payment channel; if the system detects that a payment channel does not have a corresponding token bucket, it resets / replenishes the token bucket. The payment system sends a payment instruction to the payment institution's consumer interface. It receives and verifies the payment result returned by the payment institution's consumer interface, converting it into a payment record recognizable by the payment system. Based on payment failure or anomaly results, the payment system caches various abnormal indicators, periodically monitors these indicators and thresholds, and calculates whether the system-configured thresholds have been reached. If the thresholds are reached, the routing ratio configuration information is dynamically adjusted. Based on the routing ratio configuration, the payment system periodically and dynamically calculates and adjusts the routing ratio. According to the historical number of payment orders and the number of payment orders from a single channel, it performs a secondary calibration and optimization of the routing ratio using a specified algorithm formula, which is then applied to the payment routing ratio allocation model. Finally, the payment system resets / replenishes the token count in the corresponding token bucket based on the dynamically adjusted routing ratio results and the routing ratio configuration results.

[0110] Figure 9 This is an overall flowchart provided for an embodiment of this application. Figure 9 As shown, upon receiving a payment request, the payment gateway parses the specified parameter configuration and then determines whether a specified payment channel is matched. If a specified payment channel is matched, the process ends directly. If no specified payment channel is matched, meaning the user terminal's payment request does not specify a payment channel, the payment gateway checks whether the merchant application is using a new mode. This new mode refers to the payment gateway enabling the payment routing ratio configuration method provided in this application. If the new mode is not used, the original payment routing ratio logic is used to determine the target payment channel, and the process ends. If the new mode is enabled, the payment gateway checks whether the corresponding token bucket exists. If it does not exist, the token bucket is initialized, and a token bucket replenishment step is performed. This token replenishment step requires reading the routing ratio configuration table and the dynamic routing adjustment table to read the dynamically adjusted routing ratio. The flowcharts for the routing ratio configuration table and the dynamic routing adjustment table will be provided later. Figure 11 and Figure 12 If the corresponding token bucket exists, the payment gateway will proceed with the step of consuming the token to obtain the payment channel, and then determine whether the corresponding token has been consumed. If it has been consumed, the gateway will replenish the token; otherwise, it will enter the payment process, process the payment result asynchronously, and then end the process.

[0111] Figure 10 This is a schematic diagram of a routing ratio configuration adjustment process provided in an embodiment of this application, such as... Figure 10 As shown, the payment gateway starts the process, calculates various indicators based on real-time payment statistics, and determines whether the indicators have reached the routing configuration threshold. If the threshold is not reached, the process ends. If the threshold is reached, the payment gateway calculates the dynamic ratio configuration, updates the dynamic adjustment configuration to the routing ratio configuration table, and ends the process.

[0112] Figure 11 This is a schematic diagram of a dynamic routing adjustment process provided in an embodiment of this application, such as... Figure 11 As shown, the payment gateway initiates the process by querying the routing ratio adjustment configuration and determining whether the routing ratio adjustment task is enabled. If not, the process terminates directly. If enabled, the process queries the routing ratio configuration information, dynamically calculates and adjusts the token bucket ratio, updates the routing ratio adjustment information to the dynamic routing adjustment table, and then terminates the process.

[0113] In an exemplary embodiment, this application also provides a bitrate allocation apparatus. This apparatus may include multiple functional modules for implementing the bitrate allocation method of the above method embodiments.

[0114] For example, Figure 12 This is a schematic diagram of a payment routing allocation device provided in an embodiment of this application. Figure 12As shown, the bitrate allocation device includes: an acquisition module 1201, a determination module 1202, and an operation module 1203.

[0115] The determination module 1202 is used to receive a payment request and determine the payment channel set to which the payment request belongs. The payment channel set contains at least two sub-payment channels. Different sub-payment channels correspond to their respective token buckets. The number of tokens in the token buckets corresponding to each sub-payment channel is proportional to a preset routing ratio configuration. The acquisition module 1201 is used to, in response to the payment request, acquire the current number of available tokens in the token buckets corresponding to each sub-payment channel and calculate the total number of tokens. The determination module 1202 is also used to generate a target random number within the numerical range corresponding to the total number of tokens, and determine the target sub-payment channel based on the position of the target random number within the numerical range. The operation module 1203 is used to perform a token decrement operation on the token bucket corresponding to the target sub-payment channel and perform a payment routing jump based on the target sub-payment channel to complete the payment request.

[0116] In some embodiments, the determining module 1202 is specifically used to determine the target sub-payment channel based on the position of the target random number in the numerical range, including: during the i-th traversal, obtaining the number of available tokens for the candidate sub-payment channel being traversed; determining whether the target random number is less than the number of available tokens; if it is less, determining the candidate sub-payment channel as the target sub-payment channel; otherwise, using the difference between the target random number and the number of available tokens as the target random number for the next traversal, and repeating the above process.

[0117] In some embodiments, the operation module 1203 is further configured to: configure a first token lock on the token bucket corresponding to each sub-payment channel before obtaining the current number of available tokens in the token bucket corresponding to each sub-payment channel; release the first token lock after calculating the total number of tokens; configure a second token lock on the token bucket corresponding to each sub-payment channel before performing a token decrement operation on the token bucket corresponding to the target sub-payment channel; and release the second token lock after performing a token decrement operation on the token bucket corresponding to the target sub-payment channel.

[0118] In some embodiments, the determining module 1202 is further configured to: count the actual number of payment orders for each sub-payment channel within a preset period; and dynamically adjust the routing ratio configuration based on the actual number of supported orders according to a preset calibration algorithm formula.

[0119] In some embodiments, the determining module 1202 is specifically used to determine the preset calibration algorithm formula according to the following expression: Dynamically adjusted routing ratio of sub-payment channels = (routing ratio) 2) - (Actual number of payment orders in sub-payment channels / Total number of payment orders in channels).

[0120] In some embodiments, the determining module 1202 is further configured to, after determining the payment channel set to which the payment request belongs, further include: if there is no corresponding token bucket in the payment channel set, if there is a dynamically adjusted routing ratio configuration, then obtain the token quota corresponding to each sub-payment channel based on the dynamically adjusted routing ratio configuration to construct a token bucket; if there is no dynamically adjusted routing ratio configuration, then construct the token quota corresponding to each sub-payment channel based on the preset routing ratio configuration to construct a token bucket.

[0121] In some embodiments, the determining module 1202 is further configured to receive a switching instruction; the switching instruction is used to indicate the sub-payment channel to be switched among at least two sub-payment channels; according to a preset allocation weight, the original routing ratio of the sub-payment channel to be switched is allocated to other sub-payment channels, and the routing ratio of the sub-payment channel to be switched is set to 0, thereby generating a dynamically adjusted routing ratio configuration.

[0122] In an exemplary embodiment, this application also provides a computing device. Figure 13 This is a schematic diagram illustrating the composition of a computing device provided in an embodiment of this application. Figure 13 As shown, the computing device may include a processor 1301 and a memory 1302; the memory 1302 stores instructions executable by the processor 1301; when the processor 1301 is configured to execute instructions, the computing device implements the method described in the foregoing method embodiments.

[0123] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware; for example, the related hardware can be a processor of a computing device. The program instructions can be stored in the above-described computer-readable storage medium, and when executed, they can implement the processes of the above method embodiments. The computer-readable storage medium can be memory. The above-described computer-readable storage medium can also be an external storage device, such as a hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc. Further, the above-described computer-readable storage medium can include both memory and external storage devices. The above-described computer-readable storage medium is used to store the above-described computer program instructions and other programs and data required for the above-described software package translation.

[0124] This application also provides a computer program product comprising a computer program that, when run on a computing device, causes the computing device to execute any of the software package translation methods provided in the above embodiments.

[0125] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "communication" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection. They can refer to a direct connection or an indirect connection through an intermediate medium, or a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0126] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, article, or apparatus that includes that element.

[0127] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0128] In the description of this specification, specific features, structures, materials, or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0129] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A payment route allocation method characterized by, Applied to a payment gateway, the method includes: Receive a payment request and determine the payment channel set to which the payment request belongs. The payment channel set contains at least two sub-payment channels. Different sub-payment channels correspond to their respective token buckets. The number of tokens in the token bucket corresponding to each sub-payment channel is proportional to a preset routing ratio. In response to the payment request, obtain the current number of available tokens in the token bucket corresponding to each sub-payment channel, and calculate the total number of tokens; Generate a target random number within the numerical range corresponding to the total number of tokens, and determine the target sub-payment channel based on the position of the target random number within the numerical range; The token bucket corresponding to the target sub-payment channel is decremented by one, and a payment route redirection is performed based on the target sub-payment channel to complete the payment request.

2. The method of claim 1, wherein, The step of determining the target sub-payment channel based on the position of the target random number within the numerical interval includes: During the i-th iteration, obtain the number of available tokens for the currently traversed candidate sub-payment channels; Determine whether the target random number is less than the number of available tokens; If it is less than, then the candidate sub-payment channel is determined to be the target sub-payment channel; Otherwise, the difference between the target random number and the number of available tokens is used as the target random number for the next traversal, and the above process is repeated.

3. The method according to claim 1, characterized in that, The numerical range includes the sub-numerical ranges corresponding to each sub-payment channel; The step of determining the target sub-payment channel based on the position of the target random number within the numerical interval includes: The target sub-payment channel is determined based on the sub-value range into which the target random number falls.

4. The method according to claim 1, characterized in that, The method further includes: Before obtaining the current number of available tokens in the token bucket corresponding to each sub-payment channel, a first token lock is configured for the token bucket corresponding to each sub-payment channel; after calculating the total number of tokens, the first token lock is released. Before performing a token decrement operation on the token bucket corresponding to the target sub-payment channel, a second token lock is configured on the token bucket corresponding to each sub-payment channel; after performing a token decrement operation on the token bucket corresponding to the target sub-payment channel, the second token lock is released.

5. The method according to claim 1, characterized in that, The method further includes: Statistics on the actual number of payment orders for each sub-payment channel within a preset period; Based on the preset calibration algorithm formula, the routing ratio configuration is dynamically adjusted according to the actual number of supported units.

6. The method according to claim 5, characterized in that, The routing ratio configuration includes the routing ratio corresponding to each sub-payment channel; The preset calibration algorithm formula is determined according to the following expression: Dynamically adjusted routing ratio of sub-payment channels = (routing ratio) 2) - (Actual number of payment orders in sub-payment channels / Total number of payment orders in the channels) 7. The method according to claim 1, characterized in that, After determining the payment channel set to which the payment request belongs, the method further includes: If there is no corresponding token bucket in the payment channel set, and if there is a dynamically adjusted routing ratio configuration, then the token quota corresponding to each sub-payment channel is obtained based on the dynamically adjusted routing ratio configuration in order to construct the token bucket; If there is no dynamically adjusted routing ratio configuration, the token quota for each sub-payment channel is configured based on the preset routing ratio to construct the token bucket.

8. The method according to claim 1, characterized in that, The method further includes: Receive a switching instruction; the switching instruction is used to indicate the sub-payment channel to be switched among the at least two sub-payment channels; According to the preset allocation weight, the original routing ratio of the sub-payment channel to be switched is allocated to other sub-payment channels, and the routing ratio of the sub-payment channel to be switched is set to 0, generating a dynamically adjusted routing ratio configuration.

9. A payment routing allocation device, characterized in that, The device includes: an acquisition module, a determination module, and an operation module; The determining module is used to receive a payment request and determine the payment channel set to which the payment request belongs. The payment channel set includes at least two sub-payment channels. Different sub-payment channels correspond to their respective token buckets. The number of tokens in the token bucket corresponding to each sub-payment channel is proportional to a preset routing ratio. The acquisition module is used to, in response to the payment request, acquire the current number of available tokens in the token bucket corresponding to each sub-payment channel, and calculate the total number of tokens; The determining module is further configured to generate a target random number within the numerical range corresponding to the total number of tokens, and determine the target sub-payment channel based on the position of the target random number within the numerical range; The operation module is used to decrement the token by one in the token bucket corresponding to the target sub-payment channel, and perform a payment route jump based on the target sub-payment channel to complete the payment request.

10. A computing device, characterized in that, The computing device includes a processor and a memory; the processor is coupled to the memory. The memory is used to store computer instructions; The computer instructions are loaded and executed by the processor to enable the computing device to perform the method as described in any one of claims 1-8.

Images