Dynamic Routing

Our approach

It is important to understand JusPay's implementation of dynamic routing to be able to configure gateway priorities correctly for your Merchant Account. Our approach has been to ensure maximum conversion rate and the implementation reflects this. The dynamic routing algorithm uses a non-deterministic mathematical model to rank all applicable gateways for the given transaction, using a lot of information, such as gateway health, gateway performance for a similar transaction recently, historical performance, etc.. Along with this, we take into account the priorities configured by you and arrive at the final gateway, such that the success probability is the highest.

So, please do not be surprised if a different gateway is chosen for a particular transaction which doesn't really align with your configuration. Getting you the maximum success rate is more important to us.

If a particular gateway is not applicable for a transaction, say payment mode is SBI NetBanking and gateway is HDFC PG, then that gateway will be automatically dropped by us. So, you don't have to take care of that in the priority logic.

Simple routing

Most typical routing logic would be to set up one gateway as primary and another gateway as secondary. Secondary gateway is usually used as a backup in case of primary gateway going down. However, there could be cases where a specific card BIN performs really well with the given PG and we might end up choosing the secondary gateway in such a case.

You can configure the priorities of gateways using a comma-separated string representation. For instance, say you have two gateways namely HDFC and ICICI. Now, if you need to setup HDFC as primary and ICICI as secondary, then you should configure the priorities as given below:

HDFC,ICICI

DSL

We understand that one size doesn't fit all. So, we have come up with another flexible option where you have the complete capability to dynamically set the priority.

You can describe the priority logic in Groovy code and set the priority dynamically for any given transaction. The gateways should be identified using the unique names (enumerations given below) and you are expected to setup the priority in the form of a string List. First gateway in the list has the highest priority and so will be preferred over others.

Note: Good code writing skills are necessary here. If you dont know what this is or is doubtful, please get in touch with us along with your requirement and we will help set this up for you.

Context

Transaction details are given as input to the DSL. Please see below for all the input variables that will be available to you in the DSL.

Example 1. Routing based on Channel

Example 2. Volume based routing

Example 3. Issuer based routing

Example 4. Card Brand based routing

Enforce Gateway Routing

The Enforce gateway routing can be utilised if you want to route certain set of orders/transactions to a particular payment gateway irrespective of gateway health, performance etc. For example when an offer is being provided by a certain aggregators then you would want to route transactions to that particular aggregator.

Function to be used in PL for enforcement is:
enforceGatewayPriority(["gatewayName"]);

In the above case if udf1 is passed as PG1_offer then the transaction is enforced to PG1 irrespective of health, score etc. Else the transaction can get routed to either PG2 or PG3.

List of card brands:

• VISA

• MASTERCARD

• MAESTRO

• RUPAY

• AMEX

• DINERS

• DISCOVER

List of card types:

• CREDIT

• DEBIT

List of Gateway Ids

Configure priority

Please refer to this guide to configure gateway priority logic.

Special rules

In addition to the routing logic explained above, we have also provided you with the ability to define specific rules to assign different gateway priorities for a given card BIN or card issuer bank. For instance, if you have negotiated special rates for HDFC cards on HDFC PG, then you can configure this on the dashboard.

ISIN & Issuer rules

ISIN stands for Issuer Identification Number which is card BIN (Bank Identification Number). For, a given ISIN and given Gateway, you can setup a priority score. If you wish to setup a rule for a particular card issuer bank, that can be configured too.

Score

The score is expected to be in the range of 0.0 - 2.0 (decimals are allowed). Giving a value of 2.0 will increase the priority of the gateway by 2x. A value of 0.5 will reduce the priority score by 50%. A score of 1.0 will make the rule neutral.

Issuer Routing
The issuer typically refers to the bank which has issued the credit or debit card. In some countries, even credit unions or prepaid card providers can also issue cards. You can set up rules to specify dynamic scoring for a particular issuer and a gateway

Card Brand Routing
Card Brands include VISA, MASTERCARD, MAESTRO, AMEX, RUPAY, DISCOVER, DINERS, JCB. Setup your scoring to route based on a card brand and a gateway

Dynamic Routing based on High Failures

AI-ML algorithm constantly monitor and learn high payment failures across payment ecosystem along with merchant-context and make fully automatic routing decisions

• Granular: Router takes into account high payment failures of all possible combinations of payment gateways and payment methods

• Platform level: Looks at global information on the Juspay platform across merchants

• Real-time: Identifies potential downtimes in near real-time, many times within a minute

• Accurate: Looks at a series of payment failures consecutively across board yield very high accuracy

• Contextual: When downtimes are not global and very much specific to the merchant level, Router uses merchant-level patterns and makes routing decisions

• Configurable: You configure thresholds of failures at your merchant account level, payment method level, and enable/disable payment methods to be a part of the routing algorithm. Works in conjunction with, health-based routing and static routing rules

Score
The score is expected to be in the range of 0 to 1. Algorithm maintains the score per gateway and payment method combination per 30 minute time-window. It reduces score when transaction starts and increase scores when transaction succeeds.

Whenever score falls below configured threshold, gateway decider service would look for another gateways supporting that payment method with better score.