CN111080276A

CN111080276A - Payment method, device, equipment and storage medium for withholding order

Info

Publication number: CN111080276A
Application number: CN201911409336.2A
Authority: CN
Inventors: 张健
Original assignee: Beijing Sankuai Online Technology Co Ltd
Current assignee: Beijing Sankuai Online Technology Co Ltd
Priority date: 2019-12-31
Filing date: 2019-12-31
Publication date: 2020-04-28

Abstract

The application discloses a payment method, a device, equipment and a storage medium for withholding orders, wherein the method is applied to the field of computers and comprises the following steps: acquiring a withholding order of a user account; acquiring m payment channels corresponding to the user account, wherein the payment channels support automatic deduction, and m is an integer larger than 1; determining a calling sequence according to m payment success rates corresponding to the m payment channels, wherein the payment success rate is the probability of successful payment of the internet application platform through the payment channels; and polling and calling one payment channel in the m payment channels according to the calling sequence to pay the withholding order. The method can determine the calling sequence according to the payment success rate of the payment channel, and poll and call the payment channel for payment according to the re-determined calling sequence, so that the successful probability of payment is increased.

Description

Payment method, device, equipment and storage medium for withholding order

Technical Field

The present application relates to the field of computers, and in particular, to a payment method, device, equipment, and storage medium for withholding orders.

Background

The deduction is used as a convenient payment mode and is widely used in the scenes of taxi taking, water and electricity fee, member fee deduction and the like. After a user signs a withholding agreement of a certain payment channel with a certain platform, when the user generates a withholding order in the application program, the user does not need to carry out payment operation, and the platform can automatically carry out automatic payment through the payment channel.

In the related art, there are two main types of deduction replacing methods, one is designated payment channel deduction replacing, and the other is polling deduction replacing. The appointed payment channel withholding means that a user and a platform only sign a withholding protocol of one payment channel, and the platform can only carry out withholding through one payment channel. The polling withholding means that after a withholding protocol of a plurality of payment channels (a plurality of payment platforms or a plurality of bank cards) is signed by a user and a platform, a platform initiates payment requests to the plurality of payment channels according to fixed sequence polling when the platform withholds, and when the payment of the current payment channel fails, the platform automatically initiates the payment requests to the next channel until the payment is successful or the payment of more payment channels fails.

In a polling withholding mode in the related technology, a platform initiates payment requests to a plurality of payment channels according to a fixed sequence, and when the stability of a certain payment channel before the calling sequence is poor, and the withholding is delayed or fails frequently, the problems of slow withholding speed and delayed withholding are caused.

Disclosure of Invention

The embodiment of the application provides a payment method, a device, equipment and a storage medium for withholding orders, which can solve the problems that in a polling withholding mode in the related technology, a platform initiates payment requests to a plurality of payment channels according to a fixed sequence, and when the stability of a certain payment channel in the front of a calling sequence is poor, withholding is delayed or is frequently failed, withholding speed is low and withholding is delayed. The technical scheme is as follows:

according to one aspect of the present application, there is provided a method of payment for a withheld order, the method comprising:

acquiring a withholding order of a user account, wherein the withholding order is an order for automatically withholding the user account by the withholding server;

acquiring a payment channel list corresponding to the user account, wherein the payment channel list comprises m payment channels which are signed by the user account and support automatic deduction, and m is an integer larger than 1;

determining a calling sequence of the m payment channels according to m payment success rates corresponding to the m payment channels, wherein the payment success rate is the probability of successful payment when the withholding server calls a payment server corresponding to the payment channels, the payment success rate is obtained by calculation according to at least one channel parameter of the payment channels, and the channel parameter is acquired from historical payment data of payment carried out by the payment channels;

and sequentially calling the payment server corresponding to one payment channel in the m payment channels according to the calling sequence to pay the withholding order.

According to another aspect of the present application, there is provided a payment apparatus for an withheld order, the apparatus including:

the system comprises an acquisition module, a deduction taking-off module and a deduction taking-off module, wherein the acquisition module is used for acquiring a deduction taking-off order of a user account, and the deduction taking-off order is an order for the deduction taking-off server to automatically deduct money for the user account;

the obtaining module is further configured to obtain a payment channel list corresponding to the user account, where the payment channel list includes m payment channels supporting automatic deduction signed by the user account, and m is an integer greater than 1;

the determining module is used for determining a calling sequence according to m payment success rates corresponding to the m payment channels, wherein the payment success rate is the probability of successful payment of the withholding server calling the payment server corresponding to the payment channels, the payment success rate is obtained by calculation according to at least one channel parameter of the payment channels, and the channel parameter is acquired from historical payment data of payment carried out by the payment channels;

and the payment module is used for polling and calling the payment server corresponding to one payment channel in the m payment channels according to the calling sequence to pay the withholding order.

According to another aspect of the present application, there is provided a computer device comprising: a processor and a memory having stored therein at least one instruction, at least one program, set of codes, or set of instructions that is loaded and executed by the processor to implement a method of payment for an order for deduction as described above.

According to another aspect of the present application, there is provided a computer readable storage medium having stored therein at least one instruction, at least one program, set of codes, or set of instructions that is loaded and executed by the processor to implement a payment method for an withheld order as described above.

The beneficial effects brought by the technical scheme provided by the embodiment of the application at least comprise:

when a user account initiates a withholding order, a plurality of payment channels corresponding to the user account are obtained, the calling sequence of the payment channels is determined according to the payment success rate of the payment channels, and the withholding order is paid through the payment channels according to the calling sequence polling. The payment success probability of the payment channels with the prior calling sequence is improved, the payment times of the same withholding order by calling different payment channels by the internet application platform are reduced, the withholding efficiency of the internet application platform is improved, and the withholding time delay is reduced.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a block diagram of an implementation environment for a system provided by an exemplary embodiment of the present application;

FIG. 2 is a flow chart of a method of payment for an withheld order as provided by an exemplary embodiment of the present application;

FIG. 3 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 4 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 5 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 6 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 7 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 8 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 9 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 10 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 11 is a flow chart of a method of payment for an withheld order as provided by another exemplary embodiment of the present application;

FIG. 12 is a block diagram of a payment device for a withheld order as provided by another exemplary embodiment of the present application;

fig. 13 is a schematic structural diagram of a server according to another exemplary embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

FIG. 1 is a block diagram illustrating a computer system according to an exemplary embodiment of the present application. The computer system 100 includes: terminal 110, server 120.

The terminal 110 is installed and operated with a client 111 supporting order deduction, the client 111 being an application having a deduction function, illustratively, the client 111 being an online shopping program generating an order and making deduction directly, or the client 111 being a payment program receiving an order deduction request and having a deduction function. The client 111 may be an online shopping program or an online payment program, such as a shopping program, a take-away program, a travel program, a ticketing program, a virtual resource purchasing program, a payment program, a fund management program, and the like. When the first terminal 110 runs the client 111, a user interface of the client 111 is displayed on a screen of the first terminal 110.

The clients installed on the terminal may be clients of different operating system platforms (android or IOS). The device types of the terminal include: at least one of a smartphone, a tablet, an e-book reader, an MP3 player, an MP4 player, a laptop portable computer, and a desktop computer.

Only one terminal is shown in fig. 1, but there are a plurality of other terminals 140 that may access the server 120 in different embodiments. Optionally, one or more other terminals 140 may be terminals corresponding to the developer, a development and editing platform for supporting the client 111 for order deduction is installed on the other terminals 140, the developer may edit and update the client 111 on the other terminals 140, and transmit the updated client installation package to the server 120 through a wired or wireless network, and the terminal 110 may download the client installation package from the server 120 to update the client.

The terminal 110 and the other terminals 140 are connected to the server 120 through a wireless network or a wired network.

The server 120 includes at least one of a server, a plurality of servers, a cloud computing platform, and a virtualization center. The server 120 is used for providing a background service for the client 111 supporting order deduction. Alternatively, the server 120 undertakes primary computational tasks and the terminal 110 undertakes secondary computational tasks; alternatively, the server 120 undertakes the secondary computing work and the terminal undertakes the primary computing work; alternatively, the server 120 and the terminal perform cooperative computing by using a distributed computing architecture.

Illustratively, the server is a token server. The withholding server is a server corresponding to an internet application platform for providing withholding service.

In one illustrative example, the server 120 includes a processor 122, a payment channel database 123, a withholding module 124, and a user-oriented Input/Output Interface (I/O Interface) 125. Wherein, the processor 122 is configured to load instructions stored in the server 120, and process data in the payment channel database 123 and the withholding module 124; the payment channel database 123 is used for storing data of each payment channel, such as payment orders, payment amounts, payment delays, payment success rates, and the like; the withholding module 124 is configured to poll for payment orders according to the calling order; the user-facing I/O interface 125 is used to establish communication with the terminal 110 through a wireless network or a wired network to exchange data.

In an illustrative example, the server includes a payment channel status monitoring system, a user historical payment analysis system, and a withholding system, the payment channel status monitoring system is configured to monitor a payment status of each payment channel, and the payment status includes: at least one of a payment success rate, a payment delay. The user historical payment analysis system is used for storing and analyzing the historical payment behaviors of the user, and the historical payment behaviors of the user comprise: the historical withholding order of the user, the payment result of the historical withholding order, the record of the payment request initiated by the historical withholding order to the at least one payment channel, and the payment result of the payment of the historical withholding order through the at least one payment channel. The withholding system is used for acquiring payment channel data from the payment channel state monitoring system and the user duration payment system, calculating the payment success rate of each payment channel by the payment channel data, determining a calling sequence according to the payment success rate, and polling according to the calling sequence to pay.

Fig. 2 illustrates a flow chart of a method for payment of a withheld order provided by an exemplary embodiment of the present application. The method may be performed by the server 120 in the first computer system 100 shown in FIG. 1. Illustratively, the server is a withholding server corresponding to an internet application platform providing withholding services. The method comprises the following steps:

step 101, obtaining a withholding order of a user account, wherein the withholding order is an order for automatically withholding the user account by a withholding server.

The server acquires a withholding order of the user account.

The substitute deduction is also called automatic deduction. The withholding is the behavior that the internet application platform can directly deduct money through the payment channel when the internet application platform needs to pay the withholding order after the user grants the right of withholding through the payment channel to the internet application platform. Illustratively, the withholding order is automatically generated by the internet application platform after meeting the generation conditions, and the generation conditions include: time conditions, event conditions. For example, the time condition may be a first number per month, and the event condition may be automatic purchase when the member's red envelope is used up, automatic payment when the loan reaches a certain amount, or the like. Illustratively, the withholding is a payment behavior initiated by an internet application platform, and the process from order generation to payment completion can be completed without participation of a user side. For example, withholding means that after the user is authorized, when the internet application platform generates a withholding order, the internet application platform sends a withholding instruction to the payment channel, and the payment channel withholds the electronic resource corresponding to the withholding instruction from an account of the user to the account of the internet application platform or an account specified by the withholding instruction. Illustratively, the payment user does not need to input a password, perform biological information verification or input other verification information in a withholding mode, and the generation of the withholding order and the withholding payment process do not need to be performed by the user. For example, the authorization platform a of the user a may deduct money through the payment channel a, and when the platform a generates a deduction-substituted order corresponding to the user a, the platform a deducts money directly through the payment channel a. For example, the user can automatically complete the renewal of the member per month by withholding, complete the payment of the taxi-taking order after taxi taking, complete the automatic repayment per month of the loan, and the like.

For example, the payment method of the withholding order provided by the application can also be applied to secret-free payment. The payment without secret is also called as deduction without secret. The password-free payment is a behavior that when a user initiates an order and then carries out a payment behavior, the user does not need to input a password, biological information or other verification information, and a payment channel can directly deduct money. Illustratively, the withholding is distinguished from the password-free payment in that the withholding order is initiated by the internet application platform and the password-free payment order is initiated by the user side. For example, after a user purchases a certain article, the user scans a code to pay, the user only needs to click a payment key without identity verification, and a payment channel can complete payment.

The withholding order is an order to be paid which needs to be paid in a withholding manner. For example, the withholding order may be an order generated by the server, or may be an order received by the server and sent by another server. Illustratively, the withholding order includes: at least one of a user account number, a payment amount.

Illustratively, the withholding server is a background server of the internet application platform. Illustratively, an internet application platform is a platform that provides deduction services/functionality.

Step 102, obtaining a payment channel list corresponding to the user account, where the payment channel list includes m payment channels supporting automatic deduction signed by the user account, and m is an integer greater than 1.

The server acquires a payment channel list corresponding to the user account, wherein the payment channel list comprises m payment channels which are signed by the user account and support automatic deduction, and m is an integer larger than 1.

The payment channel is a payment way which can carry out payment operations such as settlement, transfer, loan and the like on the withholding order. Illustratively, the payment channel corresponds to a payment server, and the payment is performed through the payment channel by the following method: and sending a payment request of the withholding order to a payment server corresponding to the payment channel, and transferring the electronic resources by the payment server according to the withholding order to finish payment operation. Illustratively, the payment server has stored therein electronic resources that may be used to pay for the withheld order. Illustratively, the payment server has an account of the user, and the account of the user has electronic resources stored therein, which can pay for the order.

The payment channel is a payment channel supporting automatic deduction. Illustratively, the payment channel is a payment channel having an automatic deduction function, and the user account opens the automatic deduction function. For example, the automatic deduction is also called a substitute deduction.

For example, the user account mentioned in this embodiment is a user account in a withholding server (internet application platform), another payment account is provided in a payment channel corresponding to the user account, and the payment account and the user account are different accounts. For example, the payment account and the user account may be the same account, and for example, the payment channel and the user account of the internet application platform are common. Illustratively, different payment channels correspond to different payment account numbers. For example, the user account and the payment account may be registered by the same user or the same mobile phone number, or may be registered by different users or different mobile phone numbers, and the sources of the user account and the payment account are not limited in the present application.

Illustratively, the user account authorizes the server to at least two payment channels through which surcharge payment can be made. The server acquires m payment channels which correspond to the user account and can carry out withholding payment. For example, five payment channels of the user account are stored in the server, which are an a bank card, a B bank card, a C bank card, a D payment platform and an E payment platform, respectively, wherein the user account opens a withholding authority of the a bank card, the C bank card and the D payment platform for the server, that is, the server cannot carry out withholding through the B bank card and the E payment platform, and then the server acquires the three payment channels of the a bank card, the C bank card and the D payment platform of the user account.

For example, the server may also obtain all payment channels corresponding to the user account (including a payment channel that can be deducted and a payment channel that cannot be deducted). Illustratively, after the server obtains all the payment channels corresponding to the user account, all the payment channels are sorted according to the method in step 103, and after the calling sequence is determined, the server initiates a payment request to the payment channel in which withholding payment can be performed in a polling manner, so as to perform payment for the withholding order.

And 103, determining the calling sequence of the m payment channels according to m payment success rates corresponding to the m payment channels, wherein the payment success rate is the probability of successful payment of the payment server corresponding to the payment channel called by the deduction server, the payment success rate is obtained by calculation according to at least one channel parameter of the payment channel, and the channel parameter is acquired from historical payment data of payment carried out by the payment channel.

The server determines the calling sequence of the m payment channels according to m payment success rates corresponding to the m payment channels, wherein the payment success rate is the probability of successful payment of the payment server corresponding to the payment channel called by the deduction server.

The payment success rate is the probability of successful payment of the internet application platform through the payment channel. Illustratively, the payment success rate is the probability that the internet application platform successfully completes withholding payment through the payment channel. For example, the payment success rate of a payment channel is the number of times that the internet application platform successfully pays through the payment channel/the number of times that the internet application platform initiates a payment request to the payment channel. For example, the number of times that the internet application platform initiates a payment request to the payment channel is the number of times that the internet application platform successfully pays through the payment channel + the number of times that the internet application platform fails to pay through the payment channel.

Illustratively, the internet application platform has two payment results through the payment channel. Firstly, the internet application platform initiates a payment request to a payment channel, the payment channel processes the payment request after receiving the payment request, payment can be carried out and then successful payment is returned, and payment can not be carried out or payment can not be completed due to the influence of other factors such as too long payment time and the like, and then failure in payment is returned.

Illustratively, the server determines the calling sequence of the payment channels according to m payment success rates corresponding to m payment channels and the sequence from high to low of the payment success rates.

The order of invocation is the ordering of the payment channels. Illustratively, the calling order is used to determine through which of the m payment channels a payment is made.

Illustratively, the payment success rate is calculated by the withholding server according to the channel parameters of the payment channel, and the channel parameters are collected from the historical payment data of the payment channel. The historical payment data comprises all historical orders which are paid through the withholding server, user accounts corresponding to the historical orders, payment channels, calling time of the payment channels, payment results, payment amounts, calling times of the payment channels and the like.

And step 104, sequentially calling a payment server corresponding to one payment channel of the m payment channels according to the calling sequence to pay the withholding order.

And the server calls the payment server corresponding to one payment channel in the m payment channels in sequence according to the calling sequence to pay the withholding order.

The sequential calling is that the server calls the payment server corresponding to one payment channel in the m payment channels one by one according to the calling sequence to pay the withholding order. And when the payment is successful through a certain payment channel, stopping calling the next payment channel. Sequential invocation refers to sequential invocation in order. Illustratively, the sequential calling of the m payment channels means that the 1 st payment channel is called first, if the 1 st payment channel fails to pay, the 2 nd payment channel is continuously called, if the 2 nd payment channel fails to pay, the sequential calling is continuously carried out downwards until the payment is successful through one payment channel or the payment is failed through calling the mth payment channel, and the calling is stopped. For example, the server may also poll and call a payment server corresponding to one payment channel of the m payment channels according to the call sequence to pay the withholding order. Polling calls include sequential calls or cyclic calls. Illustratively, the cyclic calling of the m payment channels means that the 1 st payment channel is called first, if the 1 st payment channel fails to pay, the 2 nd payment channel is called continuously, if the 2 nd payment channel fails to pay, the cyclic calling is called continuously downwards in sequence, if the mth payment channel still fails to pay, the first payment channel is called again to pay until the payment is successful through one payment channel or the payment is failed through calling the mth payment channel, and the call is stopped.

Illustratively, the server calls the payment servers corresponding to the m payment channels in turn in a polling manner according to a calling sequence to pay the withholding order. For example, a payment channel with a high payment success rate is preferably used for paying the withholding order.

For example, the payment method for the withholding order provided by the application can also be applied to other payment scenarios. For example, if the user has multiple payment channels selectable when making payment, the payment method of the withholding order provided by the present application may also be used to obtain the calling order of the multiple payment channels, and deduct money according to the calling order, or recommend the optimal calling order for the user. For example, the user a scans a code or performs face recognition payment on line, and after the user a scans the two-dimensional code or performs face recognition, the server obtains the payment success rates of the multiple payment channels of the user a, sorts the multiple payment channels according to the payment success rates, recommends a payment channel with a higher payment success rate for the user a, or displays the multiple payment channels in a payment channel selection interface according to the sorted order. For example, in payment scenes such as online transfer operation, payment operation, offline payment operation and the like, the user can obtain the calling sequence of a plurality of payment channels by applying the payment method of the withholding order provided by the application.

In summary, according to the method provided in this embodiment, when the user account initiates the withholding order, a plurality of payment channels corresponding to the user account are obtained, a call sequence of the plurality of payment channels is determined according to a payment success rate of the payment channels, and the withholding order is paid through the payment channels according to the call sequence polling. The payment success probability of the payment channels with the prior calling sequence is improved, the payment times of the same withholding order by calling different payment channels by the internet application platform are reduced, the withholding efficiency of the internet application platform is improved, and the withholding time delay is reduced.

The application also provides an exemplary embodiment for acquiring the payment success rate of the payment channel.

Fig. 3 illustrates a flow chart of a method for payment of a withheld order provided by an exemplary embodiment of the present application. The method may be performed by the server 120 in the first computer system 100 shown in FIG. 1. Illustratively, the server is a withholding server corresponding to an internet application platform providing withholding services. In contrast to the exemplary embodiment provided in fig. 2, step 103 comprises steps 1031 to 1033.

Step 1031, for each payment channel in the m payment channels, obtaining at least one channel parameter of the payment channel, where the channel parameter includes: at least one of a platform-level payment success rate over a recent first time period, a user-level payment success rate for a user account over a recent second time period, and a payment delay.

For each of the m payment channels, the server obtains at least one channel parameter of the payment channel.

Illustratively, the server obtains at least one channel parameter for each payment channel. The channel parameters are used for calculating the payment success rate of the payment channel. Illustratively, the channel parameters are historical parameters of the payment channel, such as order information, payment time, payment amount, payment account, target account, payment method, payment server, and the like, through which payment is made. The order information comprises at least one of an internet application platform identification, order content, order placing time, a user account and a payment channel. Illustratively, the channel parameters include at least one of a platform-level payment success rate over a recent first time period, a user-level payment success rate for the user account over a recent second time period, and a payment delay.

The platform-level payment success rate of a payment channel is the probability of successful payment in a payment request initiated by the internet application platform to the payment channel within a first time period. For example, the platform-level payment success rate user determines whether the payment is successful in the latest period of time, for example, whether the payment server corresponding to the payment channel is congested or has internal failure in the last ten minutes, resulting in always failure of payment.

The user-level payment success rate of the payment channel is the probability of successful payment in a payment request initiated by the internet application platform to the payment channel by using the order of the user account in the second time period. For example, the user-level payment success rate is used to determine whether the payment performed by the user account using the payment channel is successful within a period of time, for example, the payment performed by the user account using the payment channel always fails due to insufficient account balance.

The first time period and the second time period are periods before the server acquires m payment channels of the user account. For example, assuming that it is the third time that the server acquires the user account withholding order in step 101, or assuming that the time that the server acquires the m payment channels in step 102 is the third time, the termination time of the first time period and the second time period is before the third time. For example, the first time period and the second time period may be the same or different. For example, since the internet application platform initiates the payment request to the payment channel with the user account less frequently, the second time period is usually a longer time period, for example, seven days, one month, etc. For example, since the internet application platform initiates the payment request to the payment channel more times, the first time period is usually a short time, for example, ten minutes or one hour.

The payment delay of a payment channel is the time difference between the internet application platform (server) sending a payment request to the payment channel and the payment channel completing the payment. Illustratively, the payment delay for a payment channel is the length of time required for the payment channel to complete a payment.

Illustratively, in one exemplary embodiment, the server obtains a platform-level payment success rate, a user-level payment success rate, and a payment delay for each payment channel. That is, the server obtains 3m channel parameters for m payment channels.

Illustratively, the exemplary embodiment shown in fig. 4 shows a method for obtaining a platform-level payment success rate by a server, steps 1031-1 to 1031-2.

Step 1031-1, for each payment channel in the m payment channels, acquiring n real-time payment success rates corresponding to the n time points of the payment channel in the first time period, wherein the real-time payment success rates are real-time probabilities of successful payment of the withholding server through the payment channel, and n is a positive integer.

For each payment channel in the m payment channels, the server (the deduction system from the payment channel state monitoring system) acquires n real-time payment success rates corresponding to n time points in the first time period of the payment channel.

The real-time payment success rate of the payment channel is the ratio of the number of successful payment times through the payment channel in the server in unit time to the total number of payment times through the payment channel, and the unit time can be a certain time or a certain duration. For example, the server calculates the real-time payment success rate of the payment channel at the moment by using all payment results returned by the payment channel received at the moment of 15 hours, 36 minutes and 10 seconds. For example, the server calculates the real-time payment success rate of the payment channel by using all payment results returned by the payment channel within ten minutes before 15 hours, 36 minutes and 10 seconds. For example, the server receives 100 payment results returned by the payment channel a during a period from 15 hours 36 minutes 00 seconds to 15 hours 37 minutes 00 seconds, where 80 payments are successful and 20 payments are failed, and the real-time payment success rate of the payment channel a at 15 hours 37 minutes is 80/100-80%.

Illustratively, the server obtains a real-time payment success rate corresponding to each minute in the first time period. For example, if the first time period is from 15 hours 10 minutes to 15 hours 15 minutes, the server obtains the real-time payment success rates of a certain payment channel at 15 hours 11 minutes, 15 hours 12 minutes, 15 hours 13 minutes, 15 hours 14 minutes, and 15 hours 15 minutes, and there are 5 real-time payment success rates.

Illustratively, the real-time payment success rate of the payment channel is calculated by a payment channel state monitoring system in the server according to the payment result of the payment channel. For example, the real-time payment success rate of the payment channel may also be calculated by the deduction system after the deduction system in the server obtains the payment result of the payment channel from the payment channel state monitoring system.

And step 1031-2, determining the average value of the n real-time payment success rates as the platform-level payment success rate.

The server (the proxy deduction system) determines the average of the n real-time payment success rates as the platform-level payment success rate.

Illustratively, the platform-level payment success rate of a payment channel is an average of the real-time payment success rates of the payment channel over the first time period. For example, if the first time period is 15 hours 10 to 15 hours 15 minutes, the server obtains real-time payment success rates of a certain payment channel at 15 hours 11, 15 hours 12, 15 hours 13, 15 hours 14 and 15 hours 15 which are 0.1, 0.2, 0.3, 0.4 and 0.5, respectively, and the platform-level payment success rate of the payment channel is (0.1+0.2+0.3+0.4+0.5)/5 is 0.3.

Illustratively, the platform-level payment success rate is calculated by the withholding system in the server. Illustratively, the platform-level payment success rate may also be calculated by the payment channel status monitoring system. Illustratively, the platform-level payment success rate may also be calculated by other parts of the server, e.g. the computing system.

Illustratively, the n real-time payment success rates have different weights, e.g., the closer the time instant the greater the weight of the real-time payment success rate. As shown in fig. 5, step 1031-2 includes steps 1031-21 and steps 1031-22, which provides an exemplary embodiment for computing platform-level payment success rates based on real-time payment success rates and weights.

And 1031-21, determining the product of the real-time payment success rate and the corresponding third weight as the weighted real-time payment success rate.

And the server determines the product of the real-time payment success rate and the corresponding third weight as the weighted real-time payment success rate.

The third weight is a weight corresponding to the real-time payment success rate. Or, the third weight is a weight corresponding to the time point. Illustratively, the third weight may be any value. Illustratively, each real-time payment success rate corresponds to a third weight, and the third weights corresponding to different real-time payment success rates may be the same or different. For example, if the first time period is 15 hours 10 to 15 hours 15 minutes, the server obtains real-time payment success rates of a certain payment channel at 15 hours 11, 15 hours 12, 15 hours 13, 15 hours 14 and 15 hours 15 which are 0.1, 0.2, 0.3, 0.4 and 0.5 respectively, and their third weights are 1, 2, 3, 4 and 5 respectively, and the platform-level payment success rate of the payment channel is (0.1+ 1+0.2+ 2.3 +3+ 0.4+ 0.5)/(1 +2+3+4+5) is 0.367.

Illustratively, for convenience of calculation, the n real-time payment success rates of one payment channel correspond to n third weights, and the sum of the n third weights is 1. At this time, each real-time payment success rate is multiplied by the corresponding third weight to obtain a weighted real-time payment success rate, and the platform-level payment success rate can be obtained by adding the n weighted real-time payment success rates.

Illustratively, in step 2021, the real-time payment success rate is multiplied by the third weight to obtain a weighted real-time payment success rate.

And 1031-22, determining the average value of the n weighted real-time payment success rates as the platform-level payment success rate.

And the server determines the average value of the n weighted real-time payment success rates as the platform-level payment success rate.

Illustratively, the average of the n weighted real-time payment success rates needs to be calculated according to the n third weights. That is, the platform-level payment success rate is the sum of n weighted real-time success rates and/n third weights. Illustratively, when the sum of the n third weights is 1, the platform-level payment success rate is equal to the sum of the n weighted real-time payment success rates.

Illustratively, the exemplary embodiment shown in fig. 6 shows a method for obtaining a platform-level payment success rate by a server, steps 1031-3 to 1031-4.

And step 1031-3, acquiring a historical order of the user account in the second time period for each payment channel in the m payment channels, wherein the historical order is a withholding order for the user account to initiate a payment request to the payment channel in the second time period.

For each of the m payment channels, the server (deduction system from user historical payment analysis system) acquires the historical order of the user account in the second time period.

The historical orders corresponding to the payment channel are all orders of which the user account initiates a payment request to the payment channel through the server. Illustratively, the historical order includes the result of the payment made through the payment channel, e.g., the payment was successful or the payment failed. Illustratively, the historical orders include only orders for which the payment channel has returned payment results, not orders for which payments are being made.

Illustratively, the server acquires all orders of which the user account initiates a payment request to the payment channel within the second time period. For example, the user account a has placed 5 orders within the last three days, and 3 orders have initiated a payment request to the payment channel a, where 2 orders have been paid successfully and 1 order has failed. The server gets 3 orders that once initiated a payment request to payment channel a.

And step 1031-4, determining the proportion of the historical order number successfully paid through the payment channel to the total number of the historical orders as the user-level payment success rate.

And the server determines the proportion of the historical order number successfully paid through the payment channel to the total number of the historical orders as the user-level payment success rate.

For example, the user-level payment success rate is the number of orders that the user account successfully pays through the payment channel/the total number of orders that the user account pays through the payment channel. For example, the user account a has placed 5 orders within the last three days, and 3 orders have initiated a payment request to the payment channel a, where 2 orders have been paid successfully and 1 order has failed. The server gets 3 orders that once initiated a payment request to payment channel a with a user-level payment success rate of 2/3 of 0.667.

Illustratively, different historical orders may also be weighted differently, e.g., orders that are older may be weighted less and orders that are younger may be weighted more. As shown in fig. 7, step 1031-4 includes steps 1031-41 to steps 1031-45, which gives an exemplary embodiment of calculating a user-level payment success rate from historical orders and weights.

And 1031-41, determining a fourth weight of each historical order according to the order generation time and the total number of the historical orders, wherein the sum of the fourth weights of all the historical orders is 1.

And the server determines the fourth weight of each historical order according to the order generation time and the total number of the historical orders, and the sum of the fourth weights of all the historical orders is 1.

The fourth weight is a weight corresponding to the order generation time of the historical order. Illustratively, the later the order is generated, the greater the fourth weight. Illustratively, the fourth weight may be any value.

For example, the server obtains 5 historical orders of which the user account sent the payment request to the payment channel a, the order generation time of the 5 historical orders is five days ago, four days ago, three days ago, two days ago and one day ago, and the corresponding weights of the 5 historical orders are 1, 2, 3, 4 and 5, respectively, wherein the payment results of the historical orders before four days ago, the historical orders before three days ago and the historical orders before one day are successful, and the user-level payment success rate of the payment channel a is (2 + 1+ 3+ 1+ 5)/(1+2+ 1+ 3+ 1+ 4+ 1+ 5) ═ 0.667.

Illustratively, for convenience of calculation, the sum of all fourth weights corresponding to all historical orders is 1. At this time, the sum of the fourth weight coefficients of the history orders which are paid successfully is the user-level payment success rate.

Illustratively, the cardinality of historical orders may also vary. That is, each historical order corresponds to a different cardinality. The base number is a multiplier 1 in the formula (2 × 1+3 × 1+5 × 1)/(1 × 1+2 × 1+3 × 1+4 × 1+5 × 1) ═ 0.667, and after the base numbers corresponding to the five historical orders are changed to 1, 2, and 2, respectively, the user-level payment success rate is (2 × 1+3 × 1+5 × 2)/(1 × 1+2+3 × 1+ 4+ 2+ 5) ═ 0.625.

Step 1031-42, calculating a fifth product of the fourth weight and the cardinality of the historical order.

The server calculates a fifth product of the fourth weight and the cardinality of the historical order.

Illustratively, the server multiplies the fourth weight of each historical order by the cardinality to obtain a fifth product for the historical order.

Steps 1031-43, calculating a first cumulative sum of fifth products corresponding to the historical orders successfully paid through the payment channel.

The server calculates a first cumulative sum of fifth products corresponding to the historical orders which are successfully paid through the payment channel.

Illustratively, the server adds the fifth product of the historical orders for which payment was successful, resulting in a first cumulative sum.

Steps 1031-44, calculate a second cumulative sum of fifth products for all historical orders.

The server calculates a second cumulative sum of fifth products for all historical orders.

Illustratively, the server adds the fifth product of all historical orders to obtain a second cumulative sum.

1031-45, determining a ratio of the first cumulative sum to the second cumulative sum as a user-level payment success rate.

The server determines a ratio of the first cumulative sum to the second cumulative sum as the user-level payment success rate.

Illustratively, the user-level payment success rate is the first cumulative sum/the second cumulative sum.

For example, the server obtains 5 historical orders that the user account once initiated payment through the payment channel a, the order generation of the 5 historical orders is one month before, one week before, five days before, one day before and yesterday before, respectively, wherein the payment results of the historical orders one month before, five days before and one day before are payment success, and the payment results of the historical orders one week before and yesterday before are payment failure. And determining that the fourth weights of the 5 historical orders are 0.1, 0.2, 0.3 and 0.3 respectively according to the order generation time of the 5 historical orders, wherein the historical orders before and before five days are representative in comparison, and the base numbers of the historical orders before and before five days are changed into the base numbers of the other historical orders of 3 to be 1. As shown in table one.

Watch 1

Historical orders	One month before	One week before	Five days ago	The front day	Yesterday
						Payment result	Success of payment	Failure of payment	Success of payment	Success of payment	Failure of payment
Fourth weight	0.1	0.1	0.2	0.3	0.3
						Radix	1	1	3	3	1

Then, the fifth product of the historical order before one month is 0.1 × 1 — 0.1, the fifth product of the historical order before one week is 0.1 × 1 — 0.1, the fifth product of the historical order before five days is 0.2 × 3 — 0.6, the fifth product of the historical order before the day is 0.3 × 3 — 0.9, and the fifth product of the historical order before last day is 0.3 × 1 — 0.3. The first cumulative sum 0.1+0.6+ 0.9-1.6, the second cumulative sum 0.1+0.1+0.6+0.9+ 0.3-2, and the user-level payment success rate 1.6/2-0.8.

Step 1032, calculating to obtain a payment success rate corresponding to the payment channel according to at least one channel parameter of the payment channel.

And the server calculates and obtains the payment success rate corresponding to the payment channel according to at least one channel parameter of the payment channel.

Illustratively, the server calculates the payment success rate of one payment channel according to at least one channel parameter of platform-level payment success rate, user-level payment success rate and payment delay corresponding to the payment channel.

Illustratively, the method for calculating the payment success rate of one payment channel by the server at least comprises the following seven methods:

1. determining a platform-level payment success rate as a payment success rate;

2. determining a user-level payment success rate as a payment success rate;

3. determining a delayed payment success rate corresponding to the payment delay as a payment success rate;

4. determining the sum of the platform-level payment success rate and the user-level payment success rate as a payment success rate;

5. determining the sum of the platform-level payment success rate and the delayed payment success rate corresponding to the payment delay as the payment success rate;

6. determining the sum of the user-level payment success rate and the delayed payment success rate corresponding to the payment delay as the payment success rate;

7. and determining the sum of the platform-level payment success rate, the user-level payment success rate and the delayed payment success rate corresponding to the payment delay as the payment success rate.

For example, the above methods for calculating the payment success rate are all obtained by adding, wherein the addend (addend and addend) in each addition equation may be multiplied by a weight before adding, and then adding, taking a seventh method as an example, the payment success rate is a platform-level payment success rate + b user-level payment success rate + c delayed payment success rate corresponding to the payment delay, where a, b, and c are weights, and a, b, and c may take any number.

For example, the delayed payment success rate corresponding to the payment delay is obtained by obtaining the payment delay of the payment channel and the average payment delay of all the payment channels, and calculating a difference between the payment delay and the average payment delay, for example, the average payment delay minus the payment delay, where the difference may be a positive number or a negative number, dividing the difference by the time standard to obtain a quotient, and multiplying the quotient by the unit payment success rate to obtain the delayed payment success rate corresponding to the payment delay, where the delayed payment success rate may be a positive number or a negative number. Wherein the time standard and the unit payment success rate are a transition parameter for converting the payment delay into the payment success rate. When the payment delay is later or earlier than the average payment delay by a unit time standard, the unit payment success rate of one unit is correspondingly increased or decreased.

For example, if the payment delay of the payment channel a is 10s and the average payment delay is 8s, the difference between the payment delay and the average payment delay is-2 s, and if the time criterion is 1s and the unit payment success rate is 5%, the difference is divided by-2/1-2, and the quotient is multiplied by-2-5-10%.

Illustratively, the time standard is 200ms and the unit payment success rate is 0.5%.

Illustratively, the quotient of the difference divided by the time criterion is an integer and a decimal. That is, the delayed payment success rate must be an integer multiple of the unit payment success rate. For example, if the quotient is 3.98, the quotient is 3.

Illustratively, the delayed payment success rate has an upper and lower limit, e.g., a delayed payment success rate of up to 5% and a minimum of-5%. Illustratively, when the calculated delayed payment success rate is higher or lower than the upper and lower limits, the upper and lower limits are taken as the delayed payment success rate, for example, the upper limit of the delayed payment success rate is 5%, the lower limit is-5%, when the calculated delayed payment success rate is 8%, 5% is determined as the final delayed payment success rate, and when the calculated delayed payment success rate is-6%, 5% is determined as the final delayed payment success rate.

Illustratively, the payment success rate can be calculated by the seven methods according to the platform-level payment success rate, the user-level payment success rate and the delayed payment success rate corresponding to the payment delay. The application does not list the seven methods in detail. Exemplary embodiments of the fourth and seventh methods are given, and other kinds of calculation methods can be easily conceived by those skilled in the art according to the disclosure of the present application.

As shown in fig. 8, an exemplary embodiment of calculating a payment success rate based on a platform-level payment success rate, a user-level payment success rate, is presented. Step 1032 includes steps 1032-1 through 1032-5.

And 1032-1, acquiring a historical order of the user account in the second time period, wherein the historical order is a withholding order of the user account initiating a payment request to the payment channel in the second time period.

And the server acquires a historical order of the user account in a second time period, wherein the historical order is a withholding order for the user account to initiate a payment request to the payment channel in the second time period.

Illustratively, in synchronization step 1031-3, the server obtains all historical orders of which the user account initiated the payment request to the payment channel within the second time period.

Step 1032-2, determining a first weight and a second weight based on the quantity of the historical orders.

The server determines a first weight and a second weight based on the quantity of the historical orders.

The server obtains the number of historical orders. The server determines a second weight based on the number of historical orders. For example, the server obtains 100 historical orders for which the user account a has initiated a payment request to the payment channel a within the past ten days, and determines the second weight according to the number of the historical orders of 100. For example, the second weight may be determined according to the order quantity through a mapping relationship. For example, the order numbers 0-50 correspond to the second weight of 0.2, the order numbers 51-100 correspond to the second weight of 0.4, the order numbers 101-150 correspond to the second weight of 0.6, the order numbers 151-200 correspond to the second weight of 0.8, and the order numbers 200 and above correspond to the second weight of 1.

Illustratively, the first weight is determined in accordance with the second weight. Illustratively, the sum of the first weight and the second weight is a constant value. For example, if the sum of the first weight and the second weight is 1, the first weight is equal to 1 minus the second weight.

Illustratively, the second weight has a value in the range of 0-0.3.

At step 1032-3, a first product of the platform-level payment success rate and the first weight is calculated.

The server calculates a first product of the platform-level payment success rate and a first weight.

The server multiplies the first weight by the platform-level payment success rate to obtain a first product.

At step 1032-4, a second product of the user-level payment success rate and the second weight is calculated.

The server calculates a second product of the user-level payment success rate and a second weight.

The server multiplies the second weight by the user-level payment success rate to obtain a second product.

Step 1032-5, determining the sum of the first product and the second product as the payment success rate.

The server determines a sum of the first product and the second product as a payment success rate.

For example, the server obtains 100 of the historical amount of orders, 80% of the user-level payment success rate, 90% of the platform-level payment success rate, determines that the second weight is 0.2 according to the historical amount of orders, determines that the first weight is 0.8 according to the sum of the first weight and the second weight being 1, calculates 0.8-0.9-0.72 of the first product, calculates 0.2-0.8-0.16 of the second product, and calculates 0.16+ 0.72-0.88 of the payment success rate.

Illustratively, the channel parameters in the exemplary embodiment shown in fig. 8 further include a payment delay, the method further comprising, prior to the step 1032-3 "calculating the first product of the platform-level payment success rate and the first weight": and correcting the platform-level payment success rate according to the payment delay to obtain the corrected platform-level payment success rate.

As shown in fig. 9, an exemplary embodiment is presented for calculating a payment success rate based on a platform-level payment success rate, a user-level payment success rate, and a payment delay. Step 1032 includes steps 1032-6 through 1032-9.

And 1032-6, correcting the platform-level payment success rate according to the payment delay to obtain the corrected platform-level payment success rate.

And the server corrects the platform-level payment success rate according to the payment delay to obtain the corrected platform-level payment success rate.

Illustratively, as shown in FIG. 10, an exemplary embodiment of modifying platform-level payment success rates based on payment delays is presented. Step 1032-6 includes steps 1032-61 through 1032-62.

And 1032-61, when the payment delay corresponding to the payment channel is larger than the average payment delay, reducing the platform-level payment success rate of the payment channel to obtain the corrected platform-level payment success rate.

And when the payment delay corresponding to the payment channel is larger than the average payment delay, the server reduces the platform-level payment success rate of the payment channel to obtain the corrected platform-level payment success rate.

For example, when the payment delay corresponding to the payment channel is greater than the average payment delay, the server decreases the platform-level payment success rate of the payment channel, for example, by 5%, resulting in a modified platform-level payment success rate.

Illustratively, referring to the method for calculating the delayed payment success rate according to the payment delay, when the difference between the average payment delay and the payment delay is negative, the obtained delayed payment success rate is negative, and the platform-level payment success rate obtained in step 1031 is added to the delayed payment success rate to obtain the modified platform-level payment success rate.

And 1032-62, when the payment delay corresponding to the payment channel is smaller than the average payment delay, increasing the platform-level payment success rate of the payment channel to obtain the corrected platform payment success rate.

And when the payment delay corresponding to the payment channel is smaller than the average payment delay, the server increases the platform-level payment success rate of the payment channel to obtain the corrected platform payment success rate.

Illustratively, when the payment delay corresponding to the payment channel is greater than the average payment delay, the server increases the platform-level payment success rate of the payment channel, for example, by 5%, resulting in a modified platform-level payment success rate.

Illustratively, referring to the method for calculating the delayed payment success rate according to the payment delay, when the difference between the average payment delay and the payment delay is a positive number, the obtained delayed payment success rate is a positive number, and the platform-level payment success rate obtained in step 1031 is added to the delayed payment success rate to obtain the modified platform-level payment success rate.

Step 1032-7, a first product of the modified platform-level payment success rate and the first weight is calculated.

The server calculates a first product of the modified platform-level payment success rate and a first weight.

Illustratively, referring to the exemplary embodiment shown in fig. 8, the product of the modified platform-level payment success rate and the first weight is determined as the first product.

At step 1032-8, a second product of the user-level payment success rate and the second weight is calculated.

Illustratively, referring to the exemplary embodiment shown in FIG. 8, the product of the user-level payment success rate and the second weight is determined as the second product.

Step 1032-9, determining the sum of the first product and the second product as the payment success rate.

Illustratively, referring to the exemplary embodiment shown in FIG. 8, the payment success rate is equal to the sum of the first product and the second product.

And 1033, sequencing the m payment channels according to the sequence of the payment success rate from high to low to obtain a calling sequence.

And the server sequences the m payment channels according to the sequence of the payment success rate from high to low to obtain a calling sequence.

Illustratively, the server sorts the m payment channels according to their payment success rates to get the calling order. Illustratively, the servers are ordered by a payment success rate from high to low.

In summary, according to the method provided in this embodiment, the payment success rate of the payment channel in a past period is obtained according to the platform-level payment success rate of the payment channel, the user and payment success power, the payment delay, and other channel parameters, the call sequence is determined according to the payment success rate, the withholding order is paid according to the call sequence, and the payment success rate is improved. The payment success probability of the payment channels with the prior calling sequence is improved, the payment times of the same withholding order by calling different payment channels by the internet application platform are reduced, the withholding efficiency of the internet application platform is improved, and the withholding time delay is reduced.

By way of example, an exemplary embodiment of a payment method applying the withheld order provided herein is presented.

Fig. 11 illustrates a flow chart of a method for payment of a withheld order as provided by an exemplary embodiment of the present application. The method may be performed by the server 120 in the first computer system 100 shown in FIG. 1.

Step 901, the payment channel monitoring system calculates the real-time payment success rate of each payment channel.

Step 902, the user historical payment analysis system analyzes historical payment data of the user account.

Illustratively, the user history analysis system stores historical orders for user accounts.

Step 903, the merchant initiates a deduction substitute, and the deduction substitute system receives a round-training deduction substitute payment channel list for acquiring the user account.

Illustratively, a merchant or an internet application platform initiates a withholding request to a withholding system, sends a withholding order, the withholding system determines a user account according to the withholding order, and acquires a corresponding payment channel according to the user account.

And 904, the deduction system acquires the real-time payment success rate of the payment channel from the payment channel monitoring system and calculates the weighted platform-level payment success rate.

And 905, the withholding system acquires the payment delay of the payment channel from the payment channel monitoring system, calculates the delayed payment success rate, and corrects the weighted platform-level payment success rate by using the delayed payment success rate to obtain the corrected weighted platform-level payment success rate.

And 906, the withholding system acquires the historical payment data of the user from the historical payment analysis system of the user, calculates the success rate of user-level payment and calculates the success rate of payment according to the success rate of user-level payment and the success rate of platform-level payment.

And 907, sequencing the payment channels according to the payment success rate from high to low, and confirming the final polling deduction sequence.

In summary, in the method provided in this embodiment, the server obtains and calculates the payment success rate of the payment channel, the platform-level payment success rate, and the user-level payment success rate through the withholding system, the payment channel monitoring system, and the user-history payment analysis system, respectively, so as to improve the calculation efficiency of the payment success rate of the payment channel. The calling sequence is determined according to the payment success rate of the payment channel, the probability of successful payment of the payment channel with the calling sequence in front is improved, the times that the internet application platform calls different payment channels to pay the same withholding order are reduced, the withholding efficiency of the internet application platform is improved, and the withholding time delay is reduced.

The following are embodiments of the apparatus of the present application, and for details that are not described in detail in the embodiments of the apparatus, reference may be made to corresponding descriptions in the above method embodiments, and details are not described herein again.

Fig. 12 is a schematic structural diagram illustrating a payment device for a withheld order according to an exemplary embodiment of the present application. The device comprises:

an obtaining module 801, configured to obtain a withholding order of a user account, where the withholding order is an order for the withholding server to automatically deduct money for the user account;

the obtaining module 801 is further configured to obtain a payment channel corresponding to the user account; the payment channel list comprises m payment channels which are signed by the user account and support automatic deduction, and m is an integer larger than 1;

a determining module 802, configured to determine a calling sequence according to m payment success rates corresponding to the m payment channels, where the payment success rate is a probability that the withholding server calls a payment server corresponding to the payment channel to pay successfully, the payment success rate is calculated according to at least one channel parameter of the payment channel, and the channel parameter is acquired from historical payment data of the payment channel for payment;

and the payment module 803 is configured to poll and call the payment server corresponding to one payment channel of the m payment channels according to the call sequence, so as to pay the withholding order.

In an optional embodiment, the apparatus further comprises:

the obtaining module 801 is further configured to, for each payment channel of the m payment channels, obtain at least one channel parameter of the payment channel, where the channel parameter includes: at least one of a platform-level payment success rate over a recent first time period, a user-level payment success rate for the user account over a recent second time period, a payment delay;

a calculating module 804, configured to calculate, according to at least one channel parameter of the payment channel, a payment success rate corresponding to the payment channel;

the determining module 802 is further configured to sort the m payment channels according to a sequence from high to low of the payment success rate, so as to obtain the calling sequence.

In an alternative embodiment, the channel parameters include: the platform-level payment success rate, and, the user-level payment success rate;

the calculating module 804 is further configured to calculate a first product of the platform-level payment success rate and a first weight;

the calculating module 804 is further configured to calculate a second product of the user-level payment success rate and a second weight;

the determining module 802 is further configured to determine a sum of the first product and the second product as the payment success rate.

In an alternative embodiment, the channel parameters include: the platform-level payment success rate, the user-level payment success rate, and the payment delay;

the calculation module 804 is further configured to correct the platform-level payment success rate according to the payment delay, so as to obtain a corrected platform-level payment success rate;

the calculating module 804 is further configured to calculate a first product of the modified platform-level payment success rate and a first weight;

In an optional embodiment, the calculating module 804 is further configured to reduce the platform-level payment success rate of the payment channel to obtain the modified platform payment success rate when the payment delay corresponding to the payment channel is greater than the average payment delay;

the calculating module 804 is further configured to increase a platform-level payment success rate of the payment channel to obtain the modified platform payment success rate when the payment delay corresponding to the payment channel is smaller than the average payment delay;

wherein the average payoff delay is an average of payoff delays for all payoff channels.

In an optional embodiment, the obtaining module 801 is further configured to obtain a historical order of the user account in the second time period, where the historical order is a withholding order in which the user account initiates a payment request to the payment channel in the second time period;

the determining module 802 is further configured to determine the first weight and the second weight according to the quantity of the historical orders.

In an alternative embodiment, the channel parameters include: the platform-level payment success rate;

the obtaining module 801 is further configured to obtain n real-time payment success rates corresponding to n time points in the first time period, where the real-time payment success rate is a real-time probability that the withholding server successfully pays through the payment channel, and n is a positive integer;

the determining module 802 is further configured to determine an average of the n real-time payment success rates as the platform-level payment success rate.

In an alternative embodiment, the n time points have n third weights;

the determining module 802 is further configured to determine a product of the real-time payment success rate and the corresponding third weight as a weighted real-time payment success rate;

the determining module 802 is further configured to determine an average of the n weighted real-time payment success rates as the platform-level payment success rate.

In an alternative embodiment, the channel parameters include: the user-level payment success rate;

the obtaining module 801 is further configured to obtain a historical order of the user account in the second time period, where the historical order is a withholding order in which the user account initiates a payment request to the payment channel in the second time period;

the determining module 802 is further configured to determine, as the user-level payment success rate, a ratio of the historical amount of orders successfully paid through the payment channel to the total amount of historical orders.

In an alternative embodiment, the historical order includes an order generation time;

the determining module 802 is further configured to determine a fourth weight of each historical order according to the order generation time and the total number of the historical orders, where a sum of the fourth weights of all the historical orders is 1;

the calculating module 804 is further configured to calculate a fifth product of the fourth weight and a cardinality of the historical order;

the calculating module 804 is further configured to calculate a first cumulative sum of fifth products corresponding to the historical orders that are successfully paid through the payment channel;

the calculating module 804 is further configured to calculate a second cumulative sum of the fifth products of all the historical orders;

the determining module 802 is further configured to determine a ratio of the first cumulative sum to the second cumulative sum as the user-level payment success rate.

Fig. 13 is a schematic structural diagram of a server according to an embodiment of the present application. Specifically, the method comprises the following steps: the server 700 includes a Central Processing Unit (CPU) 701, a system Memory 704 including a Random Access Memory (RAM) 702 and a Read-only Memory (ROM) 703, and a system bus 705 connecting the system Memory 704 and the CPU 701. The server 700 also includes a basic input/output system (I/O system) 706, which facilitates transfer of information between devices within the computer, and a mass storage device 707 for storing an operating system 713, application programs 714, and other program modules 715.

The basic input/output system 706 includes a display 708 for displaying information and an input device 709, such as a mouse, keyboard, etc., for a user to input information. Wherein the display 708 and the input device 709 are connected to the central processing unit 701 through an input/output controller 710 connected to the system bus 705. The basic input/output system 706 may also include an input/output controller 710 for receiving and processing input from a number of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, an input/output controller 710 may also provide output to a display screen, a printer, or other type of output device.

The mass storage device 707 is connected to the central processing unit 701 through a mass storage controller (not shown) connected to the system bus 705. The mass storage device 707 and its associated computer-readable media provide non-volatile storage for the server 700. That is, the mass storage device 707 may include a computer-readable medium (not shown) such as a hard disk or a Compact Disc-Only Memory (CD-ROM) drive.

Without loss of generality, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash Memory or other solid state Memory technology, CD-ROM, Digital Versatile Disks (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices. Of course, those skilled in the art will appreciate that computer storage media is not limited to the foregoing. The system memory 704 and mass storage device 707 described above may be collectively referred to as memory.

According to various embodiments of the present application, server 700 may also operate as a remote computer connected to a network via a network, such as the Internet. That is, the server 700 may be connected to the network 712 through a network interface unit 711 connected to the system bus 705, or the network interface unit 711 may be used to connect to other types of networks or remote computer systems (not shown).

The present application further provides a computer device, comprising: a processor and a memory, the storage medium having stored therein at least one instruction, at least one program, set of codes, or set of instructions, which is loaded and executed by the processor to implement the method of payment for an withheld order provided by the above-described method embodiments.

The present application further provides a computer-readable storage medium having at least one instruction, at least one program, a set of codes, or a set of instructions stored therein, which is loaded and executed by a processor to implement the method for payment of an withheld order provided by the above method embodiments.

It should be understood that reference to "a plurality" herein means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

It will be understood by those skilled in the art that all or part of the steps of implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The present application is intended to cover various modifications, alternatives, and equivalents, which may be included within the spirit and scope of the present application.

Claims

1. A payment method of an order withheld is applied to a withheld server, and the method comprises the following steps:

2. The method according to claim 1, wherein the determining the calling order of the m payment channels according to the m payment success rates corresponding to the m payment channels comprises:

for each of the m payment channels, obtaining at least one of the channel parameters of the payment channel, the channel parameters including: at least one of a platform-level payment success rate over a recent first time period, a user-level payment success rate for the user account over a recent second time period, a payment delay;

calculating to obtain a payment success rate corresponding to the payment channel according to at least one channel parameter of the payment channel;

and sequencing the m payment channels according to the sequence of the payment success rate from high to low to obtain the calling sequence.

3. The method of claim 2, wherein the channel parameters comprise: the platform-level payment success rate, and, the user-level payment success rate;

the calculating the payment success rate corresponding to the payment channel according to the at least one channel parameter of the payment channel includes:

calculating a first product of the platform-level payment success rate and a first weight;

calculating a second product of the user-level payment success rate and a second weight;

determining a sum of the first product and the second product as the payment success rate.

4. The method of claim 2, wherein the channel parameters comprise: the platform-level payment success rate, the user-level payment success rate, and the payment delay;

correcting the platform-level payment success rate according to the payment delay to obtain the corrected platform-level payment success rate;

calculating a first product of the modified platform-level payment success rate and a first weight;

5. The method of claim 4, wherein the modifying the platform-level payment success rate according to the payment delay to obtain a modified platform-level payment success rate comprises:

when the payment delay corresponding to the payment channel is larger than the average payment delay, reducing the platform-level payment success rate of the payment channel to obtain the corrected platform payment success rate;

when the payment delay corresponding to the payment channel is smaller than the average payment delay, increasing the platform-level payment success rate of the payment channel to obtain the corrected platform payment success rate;

6. The method according to any one of claims 3 to 5, further comprising:

acquiring a historical order of the user account in the second time period, wherein the historical order is a withholding order of the user account initiating a payment request to the payment channel in the second time period;

and determining the first weight and the second weight according to the quantity of the historical orders.

7. The method of any of claims 2 to 5, wherein the channel parameters comprise: the platform-level payment success rate;

the obtaining of the at least one channel parameter of the payment channel includes:

acquiring n real-time payment success rates corresponding to n time points of the payment channel in the first time period, wherein the real-time payment success rate is the real-time probability of successful payment of the withholding server through the payment channel, and n is a positive integer;

and determining the average value of the n real-time payment success rates as the platform-level payment success rate.

8. The method of claim 7, wherein the n time points have n third weights;

the determining an average of the n real-time payment success rates as the platform-level payment success rate includes:

determining the product of the real-time payment success rate and the corresponding third weight as a weighted real-time payment success rate;

and determining the average value of the n weighted real-time payment success rates as the platform-level payment success rate.

9. The method of any of claims 2 to 5, wherein the channel parameters comprise: the user-level payment success rate;

and determining the proportion of the historical orders which are successfully paid through the payment channel to the total number of the historical orders as the user-level payment success rate.

10. The method of claim 9, wherein the historical orders include order generation times;

the determining the proportion of the historical orders which are successfully paid through the payment channel to the total number of the historical orders as the user-level payment success rate comprises the following steps:

determining a fourth weight of each historical order according to the order generation time and the total number of the historical orders, wherein the sum of the fourth weights of all the historical orders is 1;

calculating a fifth product of the fourth weight and a cardinality of the historical order;

calculating a first cumulative sum of fifth products corresponding to the historical orders which are paid successfully through the payment channel;

calculating a second cumulative sum of said fifth products for all of said historical orders;

determining a ratio of the first cumulative sum to the second cumulative sum as the user-level payment success rate.

11. A payment device for an order to be deducted, the device comprising:

12. A computer device, characterized in that the computer device comprises: a processor and a memory having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions that is loaded and executed by the processor to implement a method of payment for an withheld order according to any of claims 1 to 10.

13. A computer readable storage medium having stored therein at least one instruction, at least one program, a set of codes, or a set of instructions that is loaded and executed by a processor to implement a method of payment for an withheld order according to any one of claims 1 to 10.