Description:FIELD OF INVENTION
[0001] The embodiments of the present disclosure generally relate to transactions through payment gateways. More particularly, the present disclosure relates to a payment gateway routing system and method thereof.

BACKGROUND OF THE INVENTION
[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admission of the prior art.
[0003] Successful transactions play a vital role in revenue generation of any online merchant. The revenue and user experience gets adversely impacted if the success rate of transactions goes down. When a user initiates the payment process, the transaction is sent to one of the several available payment gateways (PGs). The PG then facilitates the transaction while taking a percentage of transaction amount as its fees, known as Merchant Discount Rate (MDR). In addition, merchants have commitment with several PGs to provide a pre-negotiated Gross Merchandise Value (GMV) per month. However, current systems are unable to maximize the success rate while keeping the aggregated MDR cost within a certain limit and fulfilling the GMV commitment towards each PG.
[0004] A conventional system described in literature such as Stochastic Multi-path Routing Problem with Non-stationary Rewards: Building PayU’s Dynamic Routing, formulated the problem of improving the success rate of payment gateways as reinforcement learning and used Thompson sampling to optimize the success rate.
[0005] Another conventional system described in literature such as an Artificial Intelligence (AI)-powered Smart Routing Solution for Payment Systems uses Random Forest for computing the success probability of each PG and selecting the PG with highest probability where historical time-based and event-based success probability have been used as features.
[0006] In particular, the conventional systems do not consider any constraint on the MDR and the GMV. There is, therefore, a need in the art to provide a system and a method that can mitigate the problems associated with the prior arts.

OBJECTS OF THE INVENTION
[0007] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are listed herein below.
[0008] It is an object of the present disclosure to provide a payment gateway routing system and method that improves success rate of transactions by using predictive models and satisfies constraints on Merchant Discount Rate (MDR) and Gross Merchandise Value (GMV) by using a rule-based approach.
[0009] It is an object of the present disclosure to provide a payment gateway routing system and method that provides success rate optimization, keeping achieved MDR within MDR threshold and fulfils a minimum GMV commitment towards Payment Gateways (PGs).
[0010] It is an object of the present disclosure to provide a payment gateway routing system and method that selects a PG for payment based on a success score that denotes a probability of successful transaction when routed through the respective PG.

SUMMARY
[0011] This section is provided to introduce certain objects and aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0012] In an aspect, the present disclosure relates to a payment gateway routing system that includes a processor and a memory operatively coupled with the processor. The memory stores instructions which, when executed, cause the processor to receive a request from a user device associated with a user. The request is associated with a transaction initiated by the user. The processor routes the transaction through one or more payment gateways. The processor determines if at least one payment gateway among the one or more payment gateways that comprises a corresponding Merchant Discount Rate (MDR) value within a predefined threshold for initiating a payment process. The processor, in response to a positive determination, computes a score associated with said at least one payment gateway and completes the transaction through the at least one payment gateway.
[0013] In an embodiment, in response to a negative determination, the processor may disallow the payment process through said at least one payment gateway.
[0014] In an embodiment, in response to a negative determination, the processor may determine at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a Gross Merchandise Value (GMV) score associated with said at least one another payment gateway.
[0015] In an embodiment, the processor may determine the corresponding MDR value based on a predetermined fee associated with the one or more payment gateways for completing the payment process.
[0016] In an embodiment, in response to a negative determination, the processor may disallow the payment process through said at least one payment gateway.
[0017] In an embodiment, the success score may be associated with the completion of the transaction, and the GMV score may be associated with a minimum GMV to be achieved by the one or more payment gateways.
[0018] In an embodiment, the processor may compute an achieved GMV rate and an expected GMV rate for the transaction. The processor may determine a GMV gap based on the achieved GMV rate and the expected GMV rate for the transaction for a predetermined period. The processor may generate a volume score for the transaction for the predetermined period based on the GMV gap.
[0019] In an embodiment, a magnitude of the volume score may be based on a difference between the achieved GMV rate and the expected GMV rate.
[0020] In an aspect, the present disclosure relates to a method for a payment gateway routing system, where the method includes receiving, by a processor, a request from a user device associated with a user. The request is associated with a transaction initiated by the user. The method includes routing, by the processor, the transaction through one or more payment gateways. The method includes determining, by the processor, at least one payment gateway among the one or more payment gateways that includes a corresponding MDR value within a predefined threshold for initiating a payment process. The method includes, in response to a positive determination, computing, by the processor, a score associated with said at least one payment gateway and completing the transaction through the at least one payment gateway.
[0021] In an embodiment, in response to a negative determination, the method may include determining, by the processor, at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a GMV score associated with said at least one another payment gateway.
[0022] In an embodiment, the success score may be associated with the completion of the transaction, and the GMV score may be associated with a minimum GMV to be achieved by the one or more payment gateways.

BRIEF DESCRIPTION OF DRAWINGS
[0023] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components, or circuitry commonly used to implement such components.
[0024] FIG. 1 illustrates an example network architecture (100) for implementing a proposed system (108), in accordance with an embodiment of the present disclosure.
[0025] FIG. 2 illustrates an example block diagram (200) of a proposed system (108), in accordance with an embodiment of the present disclosure.
[0026] FIG. 3 illustrates an example flow diagram of a method (300) implemented by the proposed system (108), in accordance with an embodiment of the present disclosure.
[0027] FIG. 4 illustrates an example computer system (400) in which or with which a proposed system (108) may be implemented, in accordance with an embodiment of the present disclosure.
[0028] FIG. 5 illustrates an example graphical representation of a cumulative distributive function (CDF) (500) of hourly traffic, in accordance with an embodiment of the present disclosure.
[0029] The foregoing shall be more apparent from the following more detailed description of the disclosure.

BRIEF DESCRIPTION OF THE INVENTION
[0030] In the following description, for explanation, various specific details are outlined in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0031] The ensuing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0032] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.
[0033] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0034] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.
[0035] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0036] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items.
[0037] Successful transactions involve payment processes, where the transaction is sent to one of the several available Payment Gateways (PGs). The PG then facilitates the transaction while taking a percentage of transaction amount as its fees, known as Merchant Discount Rate (MDR). In addition, merchants have commitment with several PGs to provide a pre-negotiated gross merchandise value (GMV) per month. When a transaction is routed through a given PG, then a transaction cost may be computed based on the PG MDR and a transaction amount. The payment gateway routing system described herein keeps the overall achieved MDR under a given MDR threshold as the overall MDR increases if more traffic (transactions) are routed through an individual PGs with high MDR. Hence, as long as the overall achieved MDR is less than the maximum MDR threshold, the proposed system selects the best PG out of all PGs irrespective of the PG MDR. But, as soon as the achieved overall MDR reaches the MDR threshold, the system filters out those PGs which have PG MDR greater than the threshold, allowing only the PGs having the PG MDR less than a MDR threshold. This will decrease the achieved MDR over time, after which the system will start routing through all PG’s irrespective of the PG MDR. Hence, the system guarantees that at any given time, the achieved MDR will remain below the given MDR threshold.
[0038] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGs. 1-5.
[0039] FIG. 1 illustrates an exemplary network architecture (100) for implementing a proposed system (108), in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, one or more users (102-1, 102-2…102-N) may be connected to the proposed system (108) through one or more computing devices (104-1, 104-2…104-N). A person of ordinary skill in the art will understand that the one or more users (102-1, 102-2…102-N) may be collectively referred as the users (102) and individually referred as the user (102). One or more computing devices (104-1, 104-2…104-N) may collectively referred as the computing devices (104) and individually referred as the computing device (102). It may be appreciated that the computing devices (104) may be interchangeably referred to as user device or wireless device. The computing devices (104) may be connected to the system (108) via a network (106).
[0040] In an embodiment, the computing devices (104) may include, but not be limited to, a mobile, a laptop, etc. Further, the computing devices (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, audio aid, microphone, or keyboard. Further, the computing devices (104) may include a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, and a mainframe computer. Additionally, input devices for receiving input from the user (102) such as a touchpad, touch-enabled screen, electronic pen, and the like may be used.
[0041] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.
[0042] In an embodiment, the system (108) may also be referred as a payment gateway routing system (108). The payment gateway routing system (108) may receive a request from a user device associated with a user (102). The request may be associated with a transaction initiated by the user (102). The payment gateway routing system (108) may route the transaction through one or more payment gateways, where the one or more payment gateways may initiate a payment process. For example, a single transaction may be routed through a single payment gateway.
[0043] In an embodiment, the payment gateway routing system (108) may determine at least one payment gateway among the one or more payment gateways that comprises a corresponding MDR value within a predefined threshold for completing the payment process. Payment gateways may include, but not limited to, hosted payment gateways, self-hosted payment gateways, Application Programming Interface (API)-hosted payment gateway, and local bank integration gateways. The payment gateway routing system (108) may determine the corresponding MDR based on a predetermined fee associated with the one or more payment gateways for completing the payment process. In response to a positive determination, the payment gateway routing system (108) may compute a score associated with said at least one payment gateway and complete the transaction through the at least one payment gateway. In response to a negative determination, the payment gateway routing system (108) may determine at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a GMV score associated with said at least one another payment gateway. Further, in response to a negative determination, the payment gateway routing system (108) may disallow the payment process through said at least one payment gateway.
[0044] In an embodiment, the payment gateway routing system (108) may determine if an aggregated GMV associated with said at least one payment gateway is within a target value. The target value may be configured for the one or more payment gateways for a predetermined period.
[0045] In an embodiment, the payment gateway routing system (108) may compute a score associated with said at least one payment gateway and complete the transaction through the at least one payment gateway. The payment gateway routing system (108) may determine the score based on a success score and a GMV score associated with said at least one gateway. The success score may be associated with the completion of the transaction, and the GMV score may be associated with a minimum GMV to be achieved by the one or more payment gateways.
[0046] Further, in an embodiment, the payment gateway routing system (108) may compute an achieved GMV rate and an expected GMV rate for the transaction. The payment gateway routing system (108) may determine a GMV gap based on the achieved GMV rate and the expected GMV rate for the transaction for the predetermined period. The payment gateway routing system (108) may generate a volume score for the transaction for the predetermined period based on the GMV gap. A magnitude of the volume score may be based on a difference between the achieved GMV rate and the expected GMV rate.
[0047] In an embodiment, the payment gateway routing system (108) may optimize a success rate while satisfying the MDR and GMV constraints. For example, PG1, PG2, and PG3 may be the set of PGs through which a transaction may be routed. The MDR charged by the PGs may be denoted by MDR_PG1, MDR_PG2, and MDR_PG3 respectively. Further, the MDR constraint may be implemented by the payment gateway routing system (108) to keep the overall MDR below a predefined value, for example, MDR_threshold. Also, the GMV commitment for a given month for PG1 and PG2 may be defined as promise_GMV_PG1 and promise_GMV_PG2, respectively, while no such commitment may exist for PG3. For the predetermined period from the start of the month till a current transaction, the aggregated GMV routed successfully through the respective PGs may be represented as agg_GMV_PG1, agg_GMV_PG2, and agg_GMV_PG3. Further, the constraints to be satisfied at the end of the predetermined period may be described as follows:
MDR_achieved<=MDR_threshold,
agg_GMV_PG1>=promise_GMV_PG1,
agg_GMV_PG2>=promise_GMV_PG2
[0048] In an embodiment, the payment gateway routing system (108) may keep the achieved MDR within target MDR threshold. Each PG may include a PG_MDR(%). When a transaction is routed through a given PG, then the transaction cost incurred may be represented as PG_MDR*transaction_amount. Further, the constraint may be to keep the overall achieved MDR under a given MDR threshold. The overall MDR may increase if more traffic is routed through the individual PGs with high MDR. Hence, as long as the overall achieved MDR is less than the maximum MDR threshold, the payment gateway routing system (108) may select the best PG out of all PGs irrespective of PG MDR. But, as soon as the achieved overall MDR reaches the MDR threshold, the payment gateway routing system (108) may filter out those PGs which have PG MDR greater than the threshold, hence eligible PGs may consist of only the PGs having MDR_PG less than MDR_threshold. This may decrease the achieved MDR over time, after which the payment gateway routing system (108) may again start routing through all PGs irrespective of MDR_PG. Hence, the payment gateway routing system (108) may guarantee that at any given time, the achieved MDR remains below the given MDR threshold.
[0049] In an embodiment, the payment gateway routing system (108) may select the best PG once the PGs are filtered based on MDR constraint. The final scores of remaining eligible PGs may be computed as follows:
final_score_PG1= (success_score_PG1+ GMV_score_PG1)/2
final_score_PG2= (success_score_PG2+ GMV_score_PG2)/2
final_score_PG3= (success_score_PG3+ GMV_score_PG3)/2
Where success_score may denote the probability that a transaction may be successful when routed through the respective PG and the GMV score may denote the score associated with the minimum promised GMV towards the specific PG.
[0050] In an embodiment, the payment gateway routing system (108) may compute a success score of each PG using historical success rate features of the PG at various pivots such as bank, network, and card bin. Event-based features may be used as success and failure rates of last 10, 100, and 1000 transactions for a given PG at a given pivot. In the same way, time-based success and failure rates may be used where success and failure rates may be computed using the time window of, for example, 1 hour, 2 hour, 4 hour, 15 minutes, and 5 minutes. These features may capture the real-time behaviour of PGs and help in predicting the accurate success probability of each PG for every transaction. Also, the payment gateway routing system (108) may use success and failure rates to ensure a robust system and a good performance in low traffic during night as well as during extremely high traffic of sale events.
[0051] In an embodiment, some PGs may include a contract between the merchant and an organization associated with the PG, where the merchant may promise to send a predefined GMV volume to the respective PG. Since the PG may receive the bulk volume, the PG may provide a discount and reduce the MDR_PG. If minimum volume commitment is not fulfilled by the merchant, then the MDR_PG may be charged at the original amount. Further, volume scores may be computed for every eligible PG. As the traffic is not uniform throughout the day, e.g., the traffic may drop after 1 AM in the night and increase to a maximum value around 12noon. Based on historical traffic data at hourly level, the payment gateway routing system (108) may compute the cumulative distribution function (CDF) (500) of a historical traffic. The CDF (500) for three days is shown in FIG. 5.
[0052] In an embodiment, for each transaction and every PG, the payment gateway routing system (108) may compute how much volume fraction has been achieved and how much is expected as per historical traffic CDF. Based on the gap, the payment gateway routing system (108) may compute the volume score using the following formula (as shown for PG1 at time T).
achieved_gmv_rate_PG1(T) =agg_GMV_PG1 (T) / (promise_GMV_PG1+eps)
expected_gmv_rate_PG1(T) =CDF(T)
GMV_gap_PG1(T)=max(0.0,expected_gmv_rate_PG1(T) - achieved_gmv_rate_PG1(T))
volume_score_PG1 = f(GMV_gap_PG1(T))
Where f(x)=2.0 * (1.0 / (1.0+exp(-slope_parameter * x)) - 0.5), slope_parameters=40, eps <<1, and agg_GMV_PG1(T) may denote aggregated successful GMV routed through PG1 for the time interval [0,T]. The GMV gap may be based on maximum (0, expected GMV rate, achieved GMV rate). If achieved GMV rate is lesser than the expected GMV rate, this indicates that the fulfilled GMV is lagging behind the promised GMV for a given PG. Hence, if GMV GAP is greater than 0, that may finally get converted to non-zero GMV score. Therefore, the score of the given PG increases and the given PG gets selected more often. For example, if achieved GMV of a PG is equal to a total successful GMV routed through the given PG for the predetermined period, start of the interval till current time (t), then the achieved GMV rate may be obtained as (achieved GMV of a PG till current time) / (promised GMV for the PG for entire duration of the predetermined period, e.g., predetermined period = from start till end of the month). The expected GMV rate may be equal to a value of cumulative distribution function (CDF) of the traffic at current time (t), where CDF may be precomputed for the entire predetermined period.
[0053] In an embodiment, this approach may ensure that for any given transaction (at time T), if the achieved GMV rate of a PG is above the expected GMV rate, then its volume score may be zero. Otherwise, the volume score may be non-zero and a magnitude of the volume score may depend on the gap between expected and achieved GMV rates. Also, the function f(x) may keep the magnitude of the volume score in the range [0,1]. The intuition behind using GMV score is that if the achieved GMV rate of a PG is lagging behind the expected rate at any time, then volume score of the PG may be non-zero. This will increase a final score of the PG; thus the PG will be selected more frequently. This approach may help the payment gateway routing system (108) to achieve the required volume gradually over the entire period, thus having the minimal impact on the success rate.
[0054] In an embodiment, a catboost model may be used to compute the success score of each PG. The catboost model may be a predictive where input features may be separate for each payment gateway. Further, the catboost model may be computed at various pivots such as bank, network and card bin. Event based features may be used as success and failure rates of last 10, 100 and 1000 transactions for a given payment gateway at a given pivot. In the same way, time based success and failure rates may be also be used where success and failure rates may be computed using the time window of 1 hour, 2 hour, 4 hour, 15 minutes, and 5 minutes. These features may capture real time behaviour of the one or more payment gateways. For example, for transaction related to a bank, input features may be as follows:
PG1_success_count_bank_last100_transaction,
PG1_failure_count_bank_last_1_hour,
PG1_success_count_ network_last_15_minutes
[0055] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).
[0056] FIG. 2 illustrates an example block diagram (200) of a proposed system (108), in accordance with an embodiment of the present disclosure.
[0057] Referring to FIG. 2, the system (108) may comprise one or more processor(s) (202) that may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.
[0058] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output (I/O) devices, storage devices, and the like. The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, processing engine(s) (208) and a database (210), where the processing engine(s) (208) may include, but not be limited to, a data ingestion engine (212) and other engine(s) (214). In an embodiment, the other engine(s) (214) may include, but not limited to, a data management engine, an input/output engine, and a notification engine.
[0059] In an embodiment, the processing engine(s) (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (208) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (208). In such examples, the system (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (108) and the processing resource. In other examples, the processing engine(s) (208) may be implemented by electronic circuitry.
[0060] In an embodiment, the processor (202) may receive a request via the data ingestion engine (212). The request may be received from a user device and the request may be associated with a transaction initiated by the user (102). The processor (202) may store the request in the database (210). The processor (202) may route the transaction through one or more payment gateways.
[0061] In an embodiment, the processor (202) may determine at least one payment gateway among the one or more payment gateways that comprises a corresponding MDR value within a predefined threshold for initiating a payment process. The processor (202), in response to a positive determination, may compute a score associated with said at least one payment gateway and complete the transaction through the at least one payment gateway. In response to a negative determination, the processor (202) may disallow the payment process through said at least one payment gateway. Further, in response to a negative determination, the processor (202) may determine at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a GMV score associated with said at least one another payment gateway.
[0062] In an embodiment, the processor (202) may determine the corresponding MDR value based on a predetermined fee associated with the one or more payment gateways for completing the payment process. The success score may be associated with the completion of the transaction, and the GMV score may be associated with a minimum GMV to be achieved by the one or more payment gateways.
[0063] In an embodiment, the processor (202) may compute an achieved GMV rate and an expected GMV rate for the transaction. The processor (202) may determine a GMV gap based on the achieved GMV rate and the expected GMV rate for the transaction for a predetermined period. The processor (202) may generate a volume score for the transaction for the predetermined period based on the GMV gap. A magnitude of the volume score may be based on a difference between the achieved GMV rate and the expected GMV rate.
[0064] FIG. 3 illustrates an example flow diagram of a method (300) implemented by the proposed system (108), in accordance with an embodiment of the present disclosure.
[0065] In an embodiment, the method (300) may include the following steps:
[0066] At step 302: The system (108) may receive a request from a user device associated with a user (102), where the request may be associated with a transaction initiated by the user (102).
[0067] At step 304: The system (108) may route the transaction through one or more payment gateways.
[0068] At step 306: The system (108) may determine if at least one payment gateway among the one or more payment gateways comprises a corresponding MDR value within a predefined threshold for initiating the payment process.
[0069] At step 308: The system (108) may in response to a positive determination may compute a score associated with said at least one payment gateway and complete the transaction through the at least one payment gateway.
[0070] FIG. 4 illustrates an exemplary computer system (400) in which or with which the proposed system (108) may be implemented, in accordance with an embodiment of the present disclosure.
[0071] As shown in FIG. 4, the computer system (400) may include an external storage device (410), a bus (420), a main memory (430), a read-only memory (440), a mass storage device (450), a communication port(s) (460), and a processor (470). A person skilled in the art will appreciate that the computer system (400) may include more than one processor and communication ports. The processor (470) may include various modules associated with embodiments of the present disclosure. The communication port(s) (460) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication port(s) (460) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (400) connects. The main memory (430) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (440) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (470). The mass storage device (450) may be any current or future mass storage solution, which can be used to store information and/or instructions.
[0072] The bus (420) may communicatively couple the processor (470) with the other memory, storage, and communication blocks. Optionally, operator and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (420) to support direct operator interaction with the computer system (400). Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (460). In no way should the aforementioned exemplary computer system (400) limit the scope of the present disclosure.
[0073] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.

ADVANTAGES OF THE INVENTION
[0074] The present disclosure provides a payment gateway routing system and method that improves success rate of a transaction while satisfying Merchant Discount Rate (MDR) and Gross Merchandise Value (GMV) constraints.
[0075] The present disclosure ensures that the achieved MDR never exceeds a given MDR threshold without impacting the computation of payment gateway success scores.
[0076] The present disclosure spreads the required volume commitment over a predetermined interval, while taking care of hourly traffic by converting the difference in expected and achieved GMV rates to a volume score and appending the score to the success probability.
[0077] The present disclosure improves the success rate of transactions by satisfying the constraints on the MDR and the GMV by using a rule-based approach.
, Claims:1. A payment gateway routing system (108), comprising:
a processor (202); and
a memory (204) operatively coupled with the processor (202), the memory (204) storing instructions which, when executed, cause the processor (202) to:
receive a request from a user device (104) associated with a user (102), wherein the request is associated with a transaction initiated by the user (102);
route the transaction through one or more payment gateways;
determine if at least one payment gateway among the one or more payment gateways comprises a corresponding merchant discount rate (MDR) value within a predefined threshold for initiating a payment process; and
in response to a positive determination, compute a score associated with the at least one payment gateway and complete the transaction through the at least one payment gateway.
2. The system (108) as claimed in claim 1, wherein in response to a negative determination, the processor (202) is to disallow the payment process through the at least one payment gateway.
3. The system (108) as claimed in claim 1, wherein in response to a negative determination, the processor (202) is to determine at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a Gross Merchandise Value (GMV) score associated with said at least one another payment gateway.
4. The system (108) as claimed in claim 1, wherein the processor (202) is to determine the corresponding MDR value based on a predetermined fee associated with the one or more payment gateways for completing the payment process.
5. The system (108) as claimed in claim 3, wherein the success score is associated with the completion of the transaction, and the GMV score is associated with a minimum GMV to be achieved by the one or more payment gateways.
6. The system (108) as claimed in claim 2, wherein the processor (202) is to compute:
an achieved Gross Merchandise Value (GMV) rate and an expected GMV rate for the transaction;
determine a GMV gap based on the achieved GMV rate and the expected GMV rate for the transaction for a predetermined period; and
generate a volume score for the transaction for the predetermined period based on the GMV gap.
7. The system (108) as claimed in claim 6, wherein a magnitude of the volume score is based on a difference between the achieved GMV rate and the expected GMV rate.
8. A method (300) for a payment gateway routing system (108), the method (300) comprising:
receiving (302), by a processor (202), a request from a user device (104) associated with a user (102), wherein the request is associated with a transaction initiated by the user (102);
routing (304), by the processor (202), the transaction through one or more payment gateways;
determining (306), by the processor (202), if at least one payment gateway among the one or more payment gateways comprises a corresponding Merchant Discount Rate (MDR) value within a predefined threshold for initiating a payment process; and
in response to a positive determination, computing (310), by the processor (202), a score associated with said at least one payment gateway and completing the transaction through the at least one payment gateway.
9. The method (300) as claimed in claim 8, wherein in response to a negative determination, the method (300) comprises determining, by the processor (202), at least one another payment gateway among the one or more payment gateways that comprises the MDR value within the predefined threshold based on a success score and a GMV score associated with said at least one another payment gateway.
10. The method (300) as claimed in claim 9, wherein the success score is associated with the completion of the transaction, and the GMV score is associated with a minimum GMV to be achieved by the one or more payment gateways.