CN111612442A - Payment route configuration method, device and system - Google Patents

Payment route configuration method, device and system Download PDF

Info

Publication number
CN111612442A
CN111612442A CN202010469050.XA CN202010469050A CN111612442A CN 111612442 A CN111612442 A CN 111612442A CN 202010469050 A CN202010469050 A CN 202010469050A CN 111612442 A CN111612442 A CN 111612442A
Authority
CN
China
Prior art keywords
payment
platform
payment platform
target
platforms
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010469050.XA
Other languages
Chinese (zh)
Inventor
黄志豪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Yijiqingchen Information Technology Co ltd
Original Assignee
Hangzhou Yijiqingchen Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Yijiqingchen Information Technology Co ltd filed Critical Hangzhou Yijiqingchen Information Technology Co ltd
Priority to CN202010469050.XA priority Critical patent/CN111612442A/en
Publication of CN111612442A publication Critical patent/CN111612442A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The payment route configuration method, the payment route configuration device and the payment route configuration system provided by the embodiment of the application determine a common payment platform set of a payer according to payer information, calculate the use frequency of each first payment platform in the payment platform set, the real-time load of a payment route corresponding to each first payment platform and the payment handling fee of each first payment platform, select at least one target payment platform supported by the payee under the current service scene from each first payment platform based on service scene information and payee information, calculate the priority of each target payment platform, sort each target payment platform according to the priority, and send the target payment platforms to a client for display. The above method considers the payment habits of the payee and the payer, ensures the use experience of the payee and the payer, and simultaneously calculates the priority by combining the load condition of the payment route corresponding to the payment platform so as to carry out dynamic adjustment, thereby improving the load balance of the payment route.

Description

Payment route configuration method, device and system
Technical Field
The application relates to the technical field of internet payment, in particular to a payment route configuration method, device and system.
Background
At present, with the rapid development of the internet, the number and the types of payment products are more and more, and the requirements of people on payment routing are higher and higher.
When the existing payment routing system selects the payment routing, the experience of workers is excessively relied on, the configured routing strategy has poor pertinence and low reliability, and dynamic adjustment can not be carried out according to different users and scenes, so that the user experience is poor. Therefore, how to implement dynamic configuration of payment routing is an urgent problem to be solved for different users and different scenes.
On the other hand, in the payment routing system, the load condition of each payment route at different time is different, and if the priority cannot be adjusted according to the current load of the payment route, it is inevitable that one part of the payment routes is overloaded and broken down, and the other part of the payment routes are in an idle state.
Disclosure of Invention
In view of this, an object of the present application is to provide a payment route configuration method, device and system, which implement dynamic configuration of payment routes according to priorities of the payment routes, and improve load balancing of the payment routes.
In a first aspect, an embodiment of the present application provides a payment route configuration method, which is applied to a decision engine in a payment route configuration system, where the payment route configuration system further includes a client, a plurality of payment platforms, and a plurality of payment routes, where the payment platforms and the payment routes correspond to each other one to one, and the method includes:
the method comprises the steps of obtaining payment elements in a payment request initiated by a client, wherein the payment elements comprise payment amount, payee information, payer information and service scene information;
determining a common payment platform set of a payer according to the payer information, wherein the common payment platform set of the payer comprises at least one first payment platform;
calculating the use frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform;
calculating the payment handling fee of each first payment platform according to the payment rule and the payment amount of each first payment platform;
selecting at least one target payment platform supported by a payee under the current service scene from all the first payment platforms based on the service scene information and the payee information;
respectively calculating the priority of each target payment platform according to the use frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform and the payment handling fee of each target payment platform;
and sequencing the target payment platforms in real time according to the priority of the target payment platforms, and sending the target payment platforms to the client for display.
In an optional embodiment, obtaining a common payment platform set of the payer according to the payer information includes:
acquiring the payment times of each payment platform of the payer within preset time according to the historical use information of the payer;
and acquiring a preset number of first payment platforms from high to low according to the payment times of each payment platform in a preset time to form a common payment platform set of a payer.
In an optional embodiment, calculating the usage frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform includes:
for each first payment platform, the calculation formula of the usage frequency is as follows:
Figure BDA0002513657140000021
wherein p isxFor the frequency of use, k, of the first payment platform xxThe payment times of the first payment platform x in a preset time period are calculated, and k is the sum of the payment times of all the first payment platforms;
for each first payment platform, the calculation formula of the real-time load of the corresponding payment route is as follows:
Figure BDA0002513657140000031
wherein, TxThe real-time load of the payment route corresponding to the first payment platform x is defined, n is the number of tasks to be paid currently by the payment route corresponding to the first payment platform x,
Figure BDA0002513657140000032
and averaging the execution time of the tasks of the payment route corresponding to the first payment platform x.
In an optional embodiment, the calculating the priority of each target payment platform according to the usage frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform, and the payment commission of each target payment platform includes:
for each target payment platform, the calculation formula of the priority is as follows:
Figure BDA0002513657140000033
wherein, CyPriority, p, for target payment platform yyFrequency of use, T, for target payment platform yyReal-time load of a payment route corresponding to the target payment platform y; mxThe payment commission for target paymate y, ∑ T is the sum of the real-time loads of all target paymates, ∑ M is the sum of the payment commission of all target paymates.
In an optional embodiment, before selecting, from the first payment platforms based on the current service scenario, at least one target payment platform supported by the payee under the current service scenario, the method further includes:
and acquiring a payment platform supported by each service scene preset by the payee according to different service scenes, wherein the service scenes comprise a deposit, a fixed deposit and a tail.
In an alternative embodiment, the method further comprises:
and receiving a second payment mode selected by the user from at least one target payment platform, and completing the payment request by adopting a payment route corresponding to the second payment mode.
In a second aspect, an embodiment of the present application provides a payment routing configuration apparatus, which is applied to a decision engine in a payment routing configuration system, where the payment routing configuration system further includes a client, a plurality of payment platforms, and a plurality of payment routes, where the payment platforms and the payment routes correspond to each other one to one, and the apparatus includes:
the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring payment elements in a payment request initiated by a client, and the payment elements comprise payment amount, payee information, payer information and service scene information;
the second acquisition module is used for determining a common payment platform set of the payer according to the information of the payer, wherein the common payment platform set of the payer comprises at least one first payment platform;
the first calculation module is used for calculating the use frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform;
the second calculation module is used for calculating the payment handling fee of each first payment platform according to the payment rule and the payment amount of each first payment platform;
the selection module is used for selecting at least one target payment platform supported by the payee under the current service scene from all the first payment platforms based on the service scene information and the payee information;
the priority calculation module is used for calculating the priority of each target payment platform according to the use frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform and the payment handling fee of each target payment platform;
and the sequencing module is used for sequencing the target payment platforms in real time according to the priority of the target payment platforms and sending the target payment platforms to the client for display.
In an alternative embodiment, the apparatus further comprises:
and the third acquisition module is used for acquiring payment platforms supported by various service scenes which are preset by the payee according to different service scenes, wherein the service scenes comprise a deposit, a fixed deposit and a tail.
In an alternative embodiment, the apparatus further comprises:
and the processing module is used for receiving a second payment mode selected by the user from the at least one target payment platform and completing the payment request by adopting a payment route corresponding to the second payment mode.
In a third aspect, an embodiment of the present application provides a payment route configuration system, including a decision engine, a client, multiple payment platforms, and multiple payment routes, where the payment platforms and the payment routes are in one-to-one correspondence;
the decision engine comprises a processor and a non-volatile memory storing computer instructions that, when executed by the processor, perform the payment routing configuration method of any of the preceding embodiments.
The payment route configuration method, the payment route configuration device and the payment route configuration system provided by the embodiment of the application determine a common payment platform set of a payer according to payer information, calculate the use frequency of each first payment platform in the payment platform set, the real-time load of a payment route corresponding to each first payment platform and the payment handling fee of each first payment platform, select at least one target payment platform supported by the payee under the current service scene from each first payment platform based on service scene information and payee information, calculate the priority of each target payment platform, sort each target payment platform according to the priority, and send the target payment platforms to a client for display. The above method considers the payment habits of the payee and the payer, ensures the use experience of the payee and the payer, and simultaneously calculates the priority by combining the load condition of the payment route corresponding to the payment platform so as to carry out dynamic adjustment, thereby improving the load balance of the payment route.
In order to make the aforementioned objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained from the drawings without inventive effort.
Fig. 1 is an architecture diagram of a payment routing configuration system provided in an embodiment of the present application;
FIG. 2 is a schematic diagram of a decision engine provided in an embodiment of the present application;
fig. 3 is a flowchart of a payment routing configuration method according to an embodiment of the present disclosure;
fig. 4 is a flowchart illustrating sub-steps of step S220 according to an embodiment of the present disclosure;
fig. 5 is a second flowchart of a payment routing configuration method according to an embodiment of the present application;
fig. 6 is a functional block diagram of a payment routing configuration apparatus according to an embodiment of the present application.
Description of the main element symbols: 10-payment routing configuration system; 100-a decision engine; 101-a client; 110-payment routing configuration means; 120-a memory; 130-a processor; 1101-a first acquisition module; 1102-a second obtaining module; 1103 — a first calculation module; 1104-a second calculation module; 1105-a selection module; 1106-priority calculation module; 1107-order module; 1108-a third obtaining module; 1109-processing module.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. The components of the embodiments of the present application, generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
Referring to fig. 1, fig. 1 is an architecture diagram of a payment route configuration system 10 according to an embodiment of the present disclosure, in which a payment route configuration method according to an embodiment of the present disclosure is applied to a decision engine 100 in the payment route configuration system 10, and the payment route configuration system 10 further includes a client 101, a plurality of payment platforms, and a plurality of payment routes. The payment platform corresponds to the payment route one by one.
The decision engine 100 is electrically connected to the client 101, and is capable of receiving a payment request initiated by the client 101 and obtaining a payment element in the payment request, so as to dynamically configure a payment route according to the payment element.
In the present embodiment, the decision engine 100 may be, but is not limited to, a web server, an ftp (file transfer protocol) server, and the like. The client 101 may be, but is not limited to, a smart phone, a Personal Computer (PC), a tablet PC, a Personal Digital Assistant (PDA), a Mobile Internet Device (MID), and the like.
Specifically, referring to fig. 2, fig. 2 is a schematic diagram of a decision engine 100 according to an embodiment of the present disclosure. The decision engine 100 includes a processor 130, a memory 120, and a payment routing configuration means 110. The memory 120 and the processor 130 are electrically connected to each other directly or indirectly to enable data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines. The payment routing configuration means 110 includes at least one software functional module which may be stored in the form of software or firmware (firmware) in the memory 120 or solidified in an Operating System (OS) of the decision engine 100. The processor 130 is used for executing executable modules stored in the memory 120, such as software functional modules and computer programs included in the payment routing configuration apparatus 110.
The Memory 120 may be, but is not limited to, a Random Access Memory 120 (RAM), a Read Only Memory 120 (ROM), a Programmable Read Only Memory 120 (PROM), an Erasable Read Only Memory 120 (EPROM), an electrically Erasable Read Only Memory 120 (EEPROM), and the like. The memory 120 is used for storing programs, and the processor 130 executes the programs after receiving the execution instructions.
The processor 130 may be an integrated circuit chip having signal processing capabilities. The Processor 130 may be a general-purpose Processor 130, and includes a Central Processing Unit (CPU) 130, a Network Processor (NP) 130, and the like; but may also be a digital signal processor 130(DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. The general purpose processor 130 may be a microprocessor 130 or the processor 130 may be any conventional processor 130 or the like.
The following describes in detail a payment route configuration method provided in an embodiment of the present application. Referring to fig. 3, fig. 3 is a flowchart of a payment routing configuration method according to an embodiment of the present disclosure. The method is applied to the decision engine 100 in fig. 1, and comprises the following steps:
in step S310, a payment element in the payment request initiated by the client 101 is acquired. The payment element comprises payment amount, payee information, payer information and service scene information.
Specifically, in this step, when there is a payment demand (for example, the user needs to pay after shopping in an online shopping mall), the user initiates a corresponding payment request to the decision engine 100 through the client 101, where the payment request includes payment elements such as a payment amount, payee information, payer information, and service scenario information. The service scene comprises a fixed fund, a guarantee fund, a tail fund and the like.
After receiving a payment request sent by the client 101, the decision engine 100 extracts a corresponding payment element from the payment request.
And step S320, determining a common payment platform set of the payer according to the payer information. Wherein the set of common payment platforms of the payer includes at least one first payment platform.
In this step, the decision engine 100 determines a set of common payment platforms for the payers based on the payer information included in the payment elements extracted from the payment request. The common payment platform set comprises at least one first payment platform, namely at least one payment platform with high use frequency of a user in a recent period of time.
Further, referring to fig. 4, fig. 4 is a flowchart illustrating a sub-step of step S320 according to an embodiment of the present disclosure. In the present embodiment, step S220 includes the following sub-steps:
and a substep S3201 of obtaining the payment times of the payer at each payment platform within a preset time according to the historical use information of the payer.
And a substep S3202 of obtaining a preset number of first payment platforms from high to low according to the payment times of each payment platform in a preset time to form a common payment platform set of the payer.
In the sub-steps, after the payment element is extracted, the decision engine 100 may obtain historical usage information of the payer according to the payer information included in the payment element, and obtain the payment times of each payment platform of the payer within a preset time period (for example, one month or one week) according to the historical usage information of the payer.
And then acquiring a preset number of first payment platforms from top to bottom according to the payment times of the payment platforms, thereby forming a common payment platform set of the payer.
Specifically, in this embodiment, the number (i.e., the preset number) of the first payment platforms in the common payment platform set may be set according to specific requirements. For example, the set of common payment platforms may include 1 first payment platform, 3 first payment platforms, or 5 first payment platforms.
When the common payment platform set includes 3 first payment platforms, the decision engine 100 may obtain the usage of each payment platform of the payer in the near future (for example, in the last week or in the last month) according to the historical usage information of the payer, and obtain the payment platform with the top usage ranking 3 from high to low as the first payment platform according to the usage, so as to form the common payment platform set.
With continued reference to fig. 3, in the present embodiment, after step S320, the method further includes:
step S330, calculating the usage frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform.
Specifically, in this step, for each first payment platform, its frequency of use is calculated by the following formula:
Figure BDA0002513657140000091
wherein p isxFor the frequency of use, k, of the first payment platform xxThe payment times of the first payment platform x in the preset time period are shown, and k is the sum of the payment times of all the first payment platforms.
For example, when the common payment platform set includes three first payment platforms (payment platform a, payment platform B, and payment platform C), the payment platform a makes 25 payments in the preset time period, the payment platform B makes 15 payments in the preset time period, and the payment platform C makes 10 payments in the preset time period.
The frequency of use of the payment platform a is
Figure BDA0002513657140000092
Similarly, the frequency of use of the payment platform B is about 0.3, and the frequency of use of the payment platform C is 0.2.
Of course, in other embodiments of this embodiment, the common payment platform set may further include a greater or lesser number of first payment platforms, and here, the number of first payment platforms in the common payment platform set is not specifically limited.
In addition, for each first payment platform, the real-time load of its corresponding payment route is calculated by the following formula:
Figure BDA0002513657140000101
wherein, TxThe real-time load of the payment route corresponding to the first payment platform x is defined, n is the number of tasks to be paid currently by the payment route corresponding to the first payment platform x,
Figure BDA0002513657140000102
and averaging the execution time of the tasks of the payment route corresponding to the first payment platform x.
For example, when the common payment platform set includes three first payment platforms (a payment platform a, a payment platform B, and a payment platform C), the number of tasks to be paid currently by the payment route a corresponding to the payment platform a is 50, and the average execution time of the tasks by the payment route a corresponding to the payment platform a is 1 ms; the number of tasks to be paid at present of a payment route B corresponding to a payment platform B is 100, and the average execution time of the tasks of the payment route B corresponding to the payment platform B is 0.8 ms; the number of tasks to be paid at present of the payment route C corresponding to the payment platform C is 90, and the average execution time of the tasks of the payment route C corresponding to the payment platform C is 0.5 ms.
The real-time load T of the payment route A corresponding to the payment platform AA50 × 1 is 50ms, and similarly, the real-time load of the payment route B corresponding to the payment platform B is 80ms, and the real-time load of the payment route C corresponding to the payment platform C is 45 ms.
Referring to fig. 3, after step S330, the method further includes:
step S340, calculating payment handling fee of each first payment platform according to the payment rule and payment amount of each first payment platform.
In this step, each different payment platform has a different payment rule, and it is understood that the different payment platforms may charge different (or the same) commission fees when paying the same payment amount.
Therefore, after the usage frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform are calculated, the payment handling fee that each first payment platform needs to pay additionally for the payment amount included in the payment request needs to be calculated.
Step S350, selecting at least one target payment platform supported by the payee in the current service scenario from the first payment platforms based on the service scenario information and the payee information.
In this step, when performing a transaction, in addition to considering the usage habit of the payer, it is also necessary to consider whether the first payment platform commonly used by the payer is supported by the payee.
Specifically, after the common payment platform set of the payer is obtained, at least one target payment platform needs to be selected from at least one first payment platform according to the current service scenario and the payee information.
In particular, the payment platforms supported by the payer may be different under different business scenarios. For example, when the service scenario is a subscription fee or a guarantee fee, the supported payment platform may be a payment platform a or a payment platform B; when the service scene is the collection of the payment, the supported payment platform can be a payment platform C or a payment platform D. If the common payment platform set of the payer comprises a payment platform A, a payment platform B and a payment platform C. When the service scene is the payment of the payment or the guarantee fund, the selected target payment platforms are the payment platform A and the payment platform B, and when the service scene is the payment of the tail, the selected target payment platform is the payment platform C.
In addition, it is worth to be noted that, if none of the first payment platforms included in the common payment platform set of the payer is the payment platform supported by the payee in the current business scenario, the payment platform supported by the payee is selected as the target payment platform.
For example, if the common payment platform set of the payer includes a payment platform D, when the service scenario is a subscription fee or a guarantee fee, the payment platform supported by the payee may be a payment platform a or a payment platform B, and the target payment platform is the payment platform a or the payment platform B; when the service scene is to receive the payment, the payment platform supported by the payee can be the payment platform C or the payment platform D, and the target payment platform is the payment platform D.
And step S360, calculating the priority of each target payment platform according to the use frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform and the payment handling fee of each target payment platform.
In this step, after the target payment platforms are selected, for each target payment platform, the priority of the target payment platform needs to be calculated according to the use frequency of the target payment platform, the real-time load of the corresponding payment route, and the payment commission fee.
Specifically, the calculation formula of the priority is as follows:
Figure BDA0002513657140000121
wherein, CyPriority, p, for target payment platform yyFrequency of use, T, for target payment platform yyReal-time load of a payment route corresponding to the target payment platform y; mxThe payment commission for target paymate y, ∑ T is the sum of the real-time loads of all target paymates, ∑ M is the sum of the payment commission of all target paymates.
For example, when the selected target payment platform includes a payment platform a and a payment platform B, if the usage frequency of the payment platform a is 0.5, the usage frequency of the payment platform B is 0.3, the real-time load of the payment platform a is 50ms, the real-time load of the payment platform B is 80ms, the payment commission of the payment platform a is 10 yuan, and the payment commission of the payment platform B is 15 yuan.
Then priority of payment platform a
Figure BDA0002513657140000122
Priority of Payment platform B
Figure BDA0002513657140000123
As can be seen, paymate a has a higher priority than paymate B.
Step S370, sorting the target payment platforms in real time according to the priorities of the target payment platforms, and sending the target payment platforms to the client 101 for display.
In this step, after the priority of each target payment platform is obtained by calculation according to the foregoing steps, the target payment platforms may be sorted according to the order of the priority, and sent to the client 101 for display.
Further, referring to fig. 5, fig. 5 is a second flowchart of the payment routing configuration method according to the embodiment of the present application. In this embodiment, before step S310, the method further includes:
step S309, obtaining payment platforms supported by each service scene preset by the payee according to different service scenes. The service scene comprises a guarantee fund, a fixed fund and a tail fund.
In this step, the payee may set a payment platform that can be used in each service scenario according to its own usage habit and accounting habit. The business scenario may include a deposit, a fixed deposit, a tail, and the like. In different business scenarios, the payment platforms supported by the payee may be the same or different, and the number of the payment platforms may be 1 or more.
Referring to fig. 5, in the present embodiment, the method further includes:
and step S380, receiving a second payment mode selected by the user from at least one target payment platform, and completing the payment request by adopting a payment route corresponding to the second payment mode.
In this step, after the decision engine 100 calculates the priority of each target payment platform, the priority is sorted according to the size order of the priority and displayed on the client 101. The user can select one payment platform from the multiple target payment platforms to pay, and send the selection result to the decision engine 100, and the decision engine 100 completes the payment request by adopting the payment route corresponding to the payment platform according to the selection result of the user.
To sum up, the payment route configuration method provided in the embodiment of the present application determines a common payment platform set of a payer according to payer information, calculates a usage frequency of each first payment platform in the payment platform set, a real-time load of a payment route corresponding to each first payment platform, and a payment commission of each first payment platform, selects at least one target payment platform supported by a payee in a current business scene from each first payment platform based on business scene information and payee information, calculates a priority of each target payment platform, sorts each target payment platform according to the priority, and sends the target payment platform to the client 101 for display. The above method considers the payment habits of the payee and the payer, ensures the use experience of the payee and the payer, and simultaneously calculates the priority by combining the load condition of the payment route corresponding to the payment platform so as to carry out dynamic adjustment, thereby improving the load balance of the payment route.
Referring to fig. 6, fig. 6 is a functional block diagram of a payment routing configuration apparatus 110 according to an embodiment of the present disclosure. The payment routing configuration apparatus 110 is applied to the decision engine 100 in the payment routing configuration system 10, and the payment routing configuration system 10 further includes a client 101, a plurality of payment platforms and a plurality of payment routes, where the payment platforms and the payment routes are in one-to-one correspondence, and the apparatus includes:
the first obtaining module 1101 is configured to obtain a payment element in a payment request initiated by the client 101, where the payment element includes a payment amount, payee information, payer information, and service scenario information.
The second obtaining module 1102 is configured to determine a common payment platform set of the payer according to the payer information, where the common payment platform set of the payer includes at least one first payment platform.
The first calculating module 1103 is configured to calculate a usage frequency of each first payment platform and a real-time load of a payment route corresponding to each first payment platform.
The second calculating module 1104 is configured to calculate a payment handling fee of each first payment platform according to the payment rule and the payment amount of each first payment platform.
A selecting module 1105, configured to select, from the first payment platforms, at least one target payment platform supported by the payee in the current service scenario based on the service scenario information and the payee information.
The priority calculating module 1106 is configured to calculate the priority of each target payment platform according to the usage frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform, and the payment handling fee of each target payment platform.
And the sorting module 1107 is configured to sort the target payment platforms in real time according to the priorities of the target payment platforms, and send the target payment platforms to the client 101 for display.
Referring to fig. 5, in this embodiment, the payment routing configuration apparatus further includes:
a third obtaining module 1108, configured to obtain a payment platform supported by each service scenario set by the payee in advance according to different service scenarios, where the service scenarios include a deposit, a fixed deposit, and a final payment.
And the processing module 1109 is configured to receive a second payment method selected by the user from the at least one target payment platform, and complete the payment request by using a payment route corresponding to the second payment method.
The embodiment of the present application further provides a payment route configuration system 10, which includes a decision engine 100, a client 101, a plurality of payment platforms and a plurality of payment routes, where the payment platforms and the payment routes are in one-to-one correspondence. The decision engine 100 includes a processor 130 and a non-volatile memory 120 storing computer instructions that, when executed by the processor 130, the decision engine 100 performs the payment routing configuration method described above.
It is worth noting that the payment routing configuration means provided in the embodiment of the present application may be specific hardware on the decision engine 100 or software or firmware installed on the decision engine 100, etc. The device provided by the embodiment of the present application has the same implementation principle and technical effect as the foregoing method embodiments, and for the sake of brief description, reference may be made to the corresponding contents in the foregoing method embodiments where no part of the device embodiments is mentioned. It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the foregoing systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is merely a division of one logic function, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.
Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments provided in the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U disk, a removable hard disk, a Read-Only Memory 120 (ROM), a Random Access Memory 120 (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus once an item is defined in one figure, it need not be further defined and explained in subsequent figures, and moreover, the terms "first", "second", "third", etc. are used merely to distinguish one description from another and are not to be construed as indicating or implying relative importance.
Finally, it should be noted that: the above examples are only specific embodiments of the present application, and are not intended to limit the technical solutions of the present application, and the scope of the present application is not limited thereto, although the present application is described in detail with reference to the foregoing examples, those skilled in the art should understand that: any person skilled in the art can modify or easily conceive the technical solutions described in the foregoing embodiments or equivalent substitutes for some technical features within the technical scope disclosed in the present application; such modifications, changes or substitutions do not depart from the spirit and scope of the present disclosure, which should be construed in light of the above teachings. Are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A payment route configuration method is applied to a decision engine in a payment route configuration system, the payment route configuration system further comprises a client, a plurality of payment platforms and a plurality of payment routes, wherein the payment platforms and the payment routes are in one-to-one correspondence, and the method comprises the following steps:
obtaining payment elements in a payment request initiated by the client, wherein the payment elements comprise payment amount, payee information, payer information and service scene information;
determining a common payment platform set of a payer according to the payer information, wherein the common payment platform set of the payer comprises at least one first payment platform;
calculating the use frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform;
calculating the payment handling fee of each first payment platform according to the payment rule and the payment amount of each first payment platform;
selecting at least one target payment platform supported by a payee under the current service scene from each first payment platform based on the service scene information and the payee information;
calculating the priority of each target payment platform according to the use frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform and the payment handling fee of each target payment platform;
and sequencing the target payment platforms in real time according to the priority of the target payment platforms, and sending the target payment platforms to a client for display.
2. The method as claimed in claim 1, wherein obtaining a set of common payment platforms for the payer based on the payer information comprises:
acquiring the payment times of each payment platform of a payer within preset time according to the historical use information of the payer;
and acquiring a preset number of first payment platforms from high to low according to the payment times of each payment platform in a preset time to form a common payment platform set of the payer.
3. The method of claim 1, wherein calculating the frequency of use of each of the first payment platforms and the real-time load of the payment route corresponding to each of the first payment platforms comprises:
for each first payment platform, the calculation formula of the use frequency is as follows:
Figure FDA0002513657130000021
wherein p isxFor the frequency of use, k, of the first payment platform xxThe payment times of the first payment platform x in a preset time period are calculated, and k is the sum of the payment times of all the first payment platforms;
for each first payment platform, the calculation formula of the real-time load of the corresponding payment route is as follows:
Figure FDA0002513657130000022
wherein, TxThe real-time load of the payment route corresponding to the first payment platform x is defined, n is the number of tasks to be paid currently by the payment route corresponding to the first payment platform x,
Figure FDA0002513657130000023
and averaging the execution time of the tasks of the payment route corresponding to the first payment platform x.
4. The method of claim 1, wherein calculating the priority of each target payment platform according to the usage frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform, and the payment handling fee of each target payment platform comprises:
for each target payment platform, the calculation formula of the priority is as follows:
Figure FDA0002513657130000024
wherein, CyPriority, p, for target payment platform yyFrequency of use, T, for target payment platform yyReal-time load of a payment route corresponding to the target payment platform y; mxThe payment commission for target paymate y, ∑ T is the sum of the real-time loads of all target paymates, ∑ M is the sum of the payment commission of all target paymates.
5. The method of any of claims 1-4, wherein prior to selecting from the first payment platforms at least one target payment platform supported by the payee under the current business scenario based on the current business scenario, the method further comprises:
and acquiring a payment platform supported by each service scene preset by the payee according to different service scenes, wherein the service scenes comprise a deposit, a fixed deposit and a tail.
6. The method according to any one of claims 1-4, further comprising:
and receiving a second payment mode selected by the user from at least one target payment platform, and completing the payment request by adopting a payment route corresponding to the second payment mode.
7. A payment routing configuration device is applied to a decision engine in a payment routing configuration system, wherein the payment routing configuration system further comprises a client, a plurality of payment platforms and a plurality of payment routes, wherein the payment platforms and the payment routes are in one-to-one correspondence, and the device comprises:
the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring payment elements in a payment request initiated by the client, and the payment elements comprise payment amount, payee information, payer information and service scene information;
the second acquisition module is used for determining a common payment platform set of the payer according to the payer information, wherein the common payment platform set of the payer comprises at least one first payment platform;
the first calculation module is used for calculating the use frequency of each first payment platform and the real-time load of the payment route corresponding to each first payment platform;
the second calculation module is used for calculating the payment handling fee of each first payment platform according to the payment rule and the payment amount of each first payment platform;
the selection module is used for selecting at least one target payment platform supported by a payee under the current service scene from the first payment platforms based on the service scene information and the payee information;
the priority calculation module is used for calculating the priority of each target payment platform according to the use frequency of each target payment platform, the real-time load of the payment route corresponding to each target payment platform and the payment handling fee of each target payment platform;
and the sequencing module is used for sequencing all the target payment platforms in real time according to the priority of all the target payment platforms and sending the target payment platforms to a client for display.
8. The apparatus of claim 7, further comprising:
and the third acquisition module is used for acquiring payment platforms supported by various service scenes which are preset by the payee according to different service scenes, wherein the service scenes comprise a deposit, a fixed deposit and a tail.
9. The apparatus of claim 7, further comprising:
and the processing module is used for receiving a second payment mode selected by the user from at least one target payment platform and completing the payment request by adopting a payment route corresponding to the second payment mode.
10. A payment route configuration system is characterized by comprising a decision engine, a client, a plurality of payment platforms and a plurality of payment routes, wherein the payment platforms and the payment routes are in one-to-one correspondence;
the decision engine comprising a processor and a non-volatile memory storing computer instructions that, when executed by the processor, perform the payment routing configuration method of any one of claims 1-6.
CN202010469050.XA 2020-05-28 2020-05-28 Payment route configuration method, device and system Pending CN111612442A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010469050.XA CN111612442A (en) 2020-05-28 2020-05-28 Payment route configuration method, device and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010469050.XA CN111612442A (en) 2020-05-28 2020-05-28 Payment route configuration method, device and system

Publications (1)

Publication Number Publication Date
CN111612442A true CN111612442A (en) 2020-09-01

Family

ID=72196627

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010469050.XA Pending CN111612442A (en) 2020-05-28 2020-05-28 Payment route configuration method, device and system

Country Status (1)

Country Link
CN (1) CN111612442A (en)

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080103923A1 (en) * 2006-10-31 2008-05-01 Digital River, Inc. Centralized Payment Gateway System and Method
CN105631648A (en) * 2015-12-18 2016-06-01 深圳中兴网信科技有限公司 Method and system for selecting payment platform
CN106408278A (en) * 2016-09-08 2017-02-15 北京小度信息科技有限公司 Payment method and apparatus
CN107563747A (en) * 2017-08-31 2018-01-09 拉卡拉支付股份有限公司 For being combined the method and device of payment
CN107705118A (en) * 2017-09-19 2018-02-16 深圳金融电子结算中心有限公司 Transaction payment method, system, server and storage medium based on channel route
CN108090759A (en) * 2017-12-26 2018-05-29 谢奉见 A kind of channel of disbursement Intelligent routing algorithm
CN108734460A (en) * 2018-04-02 2018-11-02 阿里巴巴集团控股有限公司 A kind of means of payment recommends method, apparatus and equipment
CN109670797A (en) * 2018-09-11 2019-04-23 深圳平安财富宝投资咨询有限公司 Pay route selecting method, apparatus, equipment and storage medium
CN109829704A (en) * 2018-12-07 2019-05-31 创发科技有限责任公司 Payment channel configuration method, device and computer readable storage medium
CN110033252A (en) * 2018-11-29 2019-07-19 阿里巴巴集团控股有限公司 A kind of channel of disbursement recommended method and device
CN110689336A (en) * 2019-09-23 2020-01-14 阿里巴巴集团控股有限公司 Payment channel decision method and device and electronic equipment
CN111144874A (en) * 2019-12-20 2020-05-12 支付宝实验室(新加坡)有限公司 Payment mode recommendation method, device and equipment

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080103923A1 (en) * 2006-10-31 2008-05-01 Digital River, Inc. Centralized Payment Gateway System and Method
CN105631648A (en) * 2015-12-18 2016-06-01 深圳中兴网信科技有限公司 Method and system for selecting payment platform
CN106408278A (en) * 2016-09-08 2017-02-15 北京小度信息科技有限公司 Payment method and apparatus
CN107563747A (en) * 2017-08-31 2018-01-09 拉卡拉支付股份有限公司 For being combined the method and device of payment
CN107705118A (en) * 2017-09-19 2018-02-16 深圳金融电子结算中心有限公司 Transaction payment method, system, server and storage medium based on channel route
CN108090759A (en) * 2017-12-26 2018-05-29 谢奉见 A kind of channel of disbursement Intelligent routing algorithm
CN108734460A (en) * 2018-04-02 2018-11-02 阿里巴巴集团控股有限公司 A kind of means of payment recommends method, apparatus and equipment
CN109670797A (en) * 2018-09-11 2019-04-23 深圳平安财富宝投资咨询有限公司 Pay route selecting method, apparatus, equipment and storage medium
CN110033252A (en) * 2018-11-29 2019-07-19 阿里巴巴集团控股有限公司 A kind of channel of disbursement recommended method and device
CN109829704A (en) * 2018-12-07 2019-05-31 创发科技有限责任公司 Payment channel configuration method, device and computer readable storage medium
CN110689336A (en) * 2019-09-23 2020-01-14 阿里巴巴集团控股有限公司 Payment channel decision method and device and electronic equipment
CN111144874A (en) * 2019-12-20 2020-05-12 支付宝实验室(新加坡)有限公司 Payment mode recommendation method, device and equipment

Similar Documents

Publication Publication Date Title
CN109101989B (en) Merchant classification model construction and merchant classification method, device and equipment
US11651398B2 (en) Contextual menus based on image recognition
CN108537533B (en) Self-service shopping settlement method and system
CN107403316A (en) Screen method, apparatus, computing device and the storage medium of the means of payment
RU2734340C1 (en) Currency type switching method and device
CN110852870A (en) Virtual resource transfer method, device, equipment and readable storage medium
CN111709777A (en) Payment mode recommendation method, system, terminal device and storage medium
CN109615410B (en) Data processing method and device, computer equipment and computer readable storage medium
CN109949042A (en) Order method of payment, device, block catenary system and storage medium
CN109102282A (en) A kind of Multiple Currencies reimbursement method for processing business and device
CN110874728A (en) Online payment system, online payment method, device, medium and server
CN108492095B (en) Transaction method and device based on block chain
CN111612442A (en) Payment route configuration method, device and system
US20210385634A1 (en) Method of determining shared service index based on shared service of communication credential
CN113657817B (en) Transaction processing method and device, electronic equipment and readable storage medium
JP2016184247A (en) Overall settlement server, overall settlement method, and program for overall settlement server
CN111091402A (en) Value data adjusting method and device, electronic equipment and readable medium
JP2023117345A (en) Method and device for providing used item transaction service using smart box
JP5902731B2 (en) Repayment simulation system
Ozyagci et al. Truthful incentive mechanism for mobile crowdsensing with smart consumer devices
CN110874331A (en) Storage address allocation method and device and electronic equipment
CN106570734B (en) Game transaction request processing method and device
KR20150042326A (en) Method for Trading Right to Use Communication Traffic or Data, and Trading-Server Used Therein
EP2901397A2 (en) Wallet based loans
JP2020071817A (en) Information processing method, information processor, and program

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination