Routing & Balancing
General Information
The routing & balancing system allows to distribute traffic between payment gates flexibly depending on the defined criteria and customer’s transaction data. Traffic can be routed to a specific group of gates/processors and distributed between them in accordance with the specified balancing. The balancing is configured on the system Project level in the Routing & Balancing tab.
One of routing types must be selected to start the configuration:
New routing block will be created. Each routing block has it’s own ID for easier navigation in big projects. The Source Card Type routing type is taken as an example:
Hover the cursor over the name of this block to select one of the following actions:
- Add routing row - to add options for this block:
Select the card types from the provided list:
- Delete node - to select another routing or balancing block instead of this one.Hover the cursor over the any criterion of this block to select one of the following actions:
- Continue Routing - to select new routing block and continue the routing strategy.
- Add balancing - to stop the routing and add the balancing block.
- to enable, disable or delete the routing option.
The default option named OTHERS is always present, it applies for transactions which don’t match all other created options.
If the created routing options are enough, click the Add balancing button to add one of the balancing types with the payment gates.
The Balance by coefficient Based on Tx Amount is taken as an example:
Blocks are connected by arrows to improve the visual presentation. An arrow is directed from a certain routing option to the block created from it. If the transaction parameters match the specified routing option, it is forwarded further along the arrow.
Hover the cursor over the name of this block to select one of the following actions:
- Add balancing row - adds the row with active fields to specify the gate:
Payment gate - the longest field is used to select one of the available payment gates.
Probability percentage - far left field. This percentage determines how likely the transaction is to go to this gate. This field exists only for balancing types with a specified coefficient.
Three empty fields at the bottom are used to redefine the payment rates.
- Delete node - to select another routing or balancing block instead of this one.
- Create group - to create a group of the balancing.
Select a group of the balancing from the provided list:
If the transaction meets the created route conditions, it will be forwarded to the balancing block with this payment gate. For more routing criteria, click the Add routing row of the required criterion, then create the subsequent transaction path from it. New block appears to the right of the selected criterion with a new number and routing type name.
The Source Card BIN routing type is taken as an example:
There is already an “OTHERS” default criterion below. As in the first case, click the Add routing row to add the appropriate criterion. Depending on the required routing strategy and the traffic separation level, go on building the routes or finish the route by adding one of the Balancing types and clicking Add balancing row to add the payment gate. The final configuration might look as the following:
Note
See the information below to check which types of routing and balancing are available and which Additional Configurations can be applied.
After the Routing & Balancing configuration is set, enable it by going to the “Project” menu, clicking the “Edit” button and selecting the “Use new balancing” check box at the bottom of the page. To confirm the selection, click “Update”.
Now, the Routing & Balancing is applied and all the traffic will go through it.
Routing Types
Several “routing types” are used in the Routing & Balancing to configure the transaction routes more flexibly.
Routing types are filters which allow to specify the traffic separation. Depending on the selected routing type, the transaction flow will be checked in relation to its parameters.
In the Routing & Balancing such routing types are represented as follows:
Source Card
The Source Card Type routing type allows to sort transactions by the sender’s card type. Select the appropriate payment methods of the sender and build a further route based on them.
2) The Card Range routing type allows to sort transactions by the sender’s card BIN value. Specify bin and choose the needed BIN range of the sender and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority. There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the “BINs -” button.
3) The Source Card Bank routing type allows to sort transactions by the sender’s Issuer Bank name. Select the needed names of sender’s Issuer Banks and build a further route based on them. There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.
The Source Card Country routing type allows to sort transactions by the sender’s card Country. Select the needed countries of the sender and build a further route based on them.
The Source Card Credit Source routing type allows to sort transactions by the sender’s card type. Select the needed card types of the sender and build a further route based on them.
Destination Card
The Destination Card Type routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.
2) The Card Range routing type allows to sort transactions by the receiver’s card BIN value. Specify bin and choose the needed BIN range of the receiver and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority. There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the “BINs -” button.
3) The Destination Card Bank routing type allows to sort transactions by the receiver’s Issuer Bank name. Select the needed Issuer Bank names of the receiver and build a further route based on them. There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.
The Destination Card Country routing type allows to sort transactions by the receiver’s card country. Select the required card countries of the receiver and build a further route based on them.
The Destination Card Credit Source routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.
Customer
The Customer Account Number Country routing type allows to sort transactions by connecting selected countries to one provider, and the remaining countries connecting to another. This routing type is used for payout transactions. Country and bank are determined by IBAN (International Bank Account Number), which has been generated in accordance with ISO 13616.
The Customer IP Country routing type allows to sort transactions by the IP address of the customer’s country. Select the countries, the IPs of which will be checked and build a further route based on them.
The Customer IP Range routing type allows to sort transactions which IP address values are within the specified range. Specify the appropriate IP range and build the further route from it. Both IPv4 and IPv6 are accepted.
Customer Billing Country routing type allows to sort transactions by the country from the customer’s billing address. Select the needed countries and build a further route based on them.
Customer Loyalty routing type is divided into endpoint, project, merchant, manager. Each of these levels has a Returning customer approve sessions count field that can be set for Managers by users with Superior role, while for Projects, Endpoints and Merchants - by users with Manager role.
This value sets the number of transactions after which the customer will be considered “RETURNING”. Select the loyalty types and build a further route based on them. Also, in an Endpoint settings, you can set the parameters by which the client will be defined. This option is called Client definition. Definition is possible by card number, email, card holder and email, card holder and purpose, card holder and phone. For RETURNING_FOR_MERCHANT, RETURNING_FOR_MANAGER and RETURNING_FOR_ENDPOINT the client definition is taken from Endpoint. For RETURNING_FOR_PROJECT the client definition is taken from Project.
by Recurring and Non_recurring routing types allows to sort transactions based on whether transaction type is recurrent or not.
by purpose routing type allows to sort transactions based on purpose. It is possible to enter more than one purpose value to each routing row. New values are added using the Add button which is available when editing or creating. Purpose limited to 128 symbols.
by Phone IMEI (IMEI or International Mobile Equipment Identity) — this is the individual number of the mobile equipment. It is possible to enter more than one purpose value to each routing row. IMEI limited to 32 symbols.
by Customer Instance routing type allows to sort transactions based on Customer payment history for the whole instance. Please contact tech Support manager to enable this functionality.
Select the Customer type for instance and build a further route based on them. The client is defined as NEW or RETURNING based on criteria set on the Project level (by default) or Endpoint level (if specified). This option is called Client definition. Definition is possible by card number, email, card holder and email, card holder and purpose, card holder and phone.
Note
Transaction
Transaction Amount routing type allows to sort transactions by their amounts. The number in the square bracket is included in the range and the number in the round bracket is not included in the range. For example, to specify amount from 0 to 100 (including 100), use [0, 100.01). Transactions, which amounts match the specified range, will pass through this routing criterion.
Transaction Type routing type allows to sort transactions by their type. Select the needed transaction types and build a further route based on them.
Amount Multiplicity routing type allows to sort transactions by their amounts matching with specified multipliers. Add amount multiplicity and transaction will route by the highest amount to which it is a multiple. Example: If transaction amount is 1000 and “Amount multiplicity” is settled as 1000 and 500, transaction will route to 1000, and if transaction amount is 1500 it will route to 500, and if transaction amount is 2000 it will route to 1000.
Transaction Time routing type allows to sort transactions by the time they are created in the system. Timezone GMT+3. This sort type can be used for processor technical breaks or for any other reason when time is necessary for any route. To set the time, for example, from 22:00 till 06:00, set the time the following way: [22:00:00, 23:59:59], [00:00:00, 06:00:00].
Day of week routing type allows to sort transactions by day of the week. Select the needed day of the week and time zone for further route based on them.
Transfer
Transfer Direction routing type allows to sort transfer transactions by card types or Issuer banks of sender and receiver. Select the needed parameters and build a further route based on them.
IP Intelligence
Warning
If Fraud Service - “MaxMind IP check service” is selected on project level, then regardless of whether “fraud filters” or “routing&balancing” are set up - all requests will be send to Max Mind.
Anonymous vpn routing type allows to check when Payer IP address is considered as anonymous vpn by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Anonymous IP address routing type allows to check when Payer IP address is considered as anonymous by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Hosting provider routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Public proxy routing type allows to check when Payer IP address belongs to a public proxy considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Residential proxy routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Tor exit node routing type allows to check when Payer IP address a Tor exit node considered by MaxMind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.
Static IP score routing type allows to check when Payer IP address Static IP score which is considered by MaxMind service is lower or equal to the settled threshold value. Higher values meaning a greater static association. For example, many IP addresses with a user type of cellular have a score under one. Broadband IPs that don’t change very often typically have a score above thirty. This indicator can be useful for deciding whether an IP address represents the same user over time. The value ranges from 0 to 99.99. Select the needed parameters and build a further route based on them.
User count routing type allows to check when Payer IP address user count considered by MaxMind service is higher or equal to the settled threshold value. The estimated number of users sharing the IP/network during the past 24 hours. For IPv4, the count is for the individual IP. For IPv6, the count is for the /64 network. Select the needed parameters and build a further route based on them.
Balancing Types
Balancing type is a feature which allows to distribute transactions between payment gates in accordance with the configured parameters.
Note
The gate can also be specified directly on the endpoint. However, it will still be subject to the routing strategy, but will be selected for all transactions coming from this endpoint on this route.
The following balancing types are presented in the system:
Balance By Coefficient
Balance by coefficient Based on Tx Amount allows to sort transactions by the gates depending on the amount and the specified probability percentage.
For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, 50% of the first several processed transactions will be forwarded to the gate with the probability of 50%, then the traffic will try to reach the distribution of the amount between the gates in accordance with the specified percentages. If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal to the percentages set for the gates.
Balance by coefficient Based on Tx Count allows to sort transactions by gates depending on their quantity and the specified probability percentage.
For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, 50% of the processed transactions will be forwarded to the gate with the probability of 50%. The transaction amounts are not considered, only their quantity is.
Balance Equally
Balance equally Based on Tx Amount allows to sort transactions by gates depending on the amount with equal probability percentage.
If there are e.g. 4 gates, “Balance equally on Tx Amount” will set an equal probability percentage of 25% for each gate. The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution of the amount between the gates. If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal.
Balance equally Based on Tx Count allows to sort transactions by gates depending on the quantity with equal probability percentage.
If there are e.g. 4 gates, “Balance equally on Tx Count” will set an equal probability percentage of 25% for each gate. The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution between the gates based on the quantity of transactions.
Cascading Chain
Chain by Coefficient Based on Tx Count allows to sort transactions by gates using the specified probability percentage and the chain principle. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones according to their coefficients.
For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, the gate with 50% coefficient has the 50% probability of becoming the first gate in the formed chain. If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain. If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it. The traffic will try to reach the distribution between the gates according to their coefficients based on the quantity of transactions.
Chain by Equivalently Based on Tx Count allows to sort transactions by gates using the chain principle and an equal probability percentage. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones based on equal probability percentage.
If there are e.g. 4 gates, “Chain by equivalently on Tx Count” will set an equal probability percentage of 25% for each gate. In this case, each gate has the 25% probability of becoming the first gate in the formed chain. If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain. If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it. The traffic will try to reach the equal distribution between the gates based on the quantity of transactions.
Chain by Sequence allows to sort transactions using the cascading chain principle.
Transactions will be processed by gates only in a priority order. If for some reason the first gate in the chain was not able to process the transaction, it moves further along the chain until one of the subsequent gates in chain processes it. The gate priority can be changed in “Chain by Sequence” using drag’n’drop.
Chain by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status and the chain principle.
All client transactions (defined by email) are checked within the exact processor (not among all of them) and the next transaction is routed to the gate with last successful transaction of this client. If attempt on this gate was declined, transaction moves further along the chain until one of the subsequent gates in chain processes it.
Others
First in Sequence allows to sort transactions by choosing the first appropriate gate for them.
If the incoming transaction is going to be filtered or exceed the limits on certain gates, the “First in Sequence” algorithm excludes these gates and then it sends the transaction to the highest gate of the remaining ones. The gate priority can be changed by dragging it up and down.
First in Sequence by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status.
All client(by e-mail) transactions for all projects are checked and the next transaction is routed to the gate with processor of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Also, all gates belonging to the same processor as the gate on which the rejection status occurred receive low priority. Gate with processor with last approved transaction will be first in sequence, a gate with processor with earlier approves or no approves will be last.
First in Sequence by Last Customer Tx Status on Gate allows to sort transactions by resulting transaction status.
All client(by e-mail) transactions are checked and the next transaction is routed to the gate of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Unlike First in Sequence by Last Customer Tx Status on Acquirer balancing type, the gates belonging to the same processor as the gate on which the declined status occurred do not lose priority and do not fall at the end of the sequence. Gate with last approved transaction will be first in sequence, a gate with earlier approves or no approves will be last.
Additional Configurations
Gate Skips
The gates in the balancing block can be skipped for processing of the transaction in the following cases:
1.) If Acquirer restrictions on gate level is triggered;
2.) For Cascading chain options - if the decline message specified in Chain Strategy Details or Chain Strategy Skips is received, the chain will stop;
3.) If the gate is disabled on the gate level;
4.) If the gate is disabled in balancing block;
5.) If gate is set to be ignored, because it’s intended only for direct processing from specific Endpoints (see Ignore Gates For Direct Processing below).
Ignore Gates For Direct Processing
Ignoring gates - ignores selected gate for whole node.
If it is needed to use gate, but only for the specific Endpoint without any changes in the routing, use Ignoring gates, so that way this gate will be ignored for the rest of the traffic and will only be used with the specific Endpoint.
Rates
Rates is a system of payment fees for all stakeholders’ services.
The system supports such stakeholders as:
Merchant, Reseller, Manager, Dealer, Bank.
In the current model, the fees are incrementally increasing, from the Bank to the Merchant. The following rate plan will count the value of the previous one. Thus, the higher the participant’s level is, the greater his total fee is in the system. The Bank and Dealer rate plans can be set on the gate level. Manager, Reseller, and Merchant rate plans can be set on the project level, with the option to override them on the endpoint level. The presence of some participants in the payment rates model is optional.
In Routing & Balancing the Rates can be redefined directly on the gates configuration in balancing blocks. These Rates settings override the ones on project or endpoint level.
There are 3 active fields below at the gate’s name, which are responsible for redefining rate plans for Manager, Reseller and Merchant, from left to right respectively. All rate plans can be selected from the dropdown list of already created ones.
Copy, Paste, Cut, Delete
Routing & balancing nodes can be deleted, along with all children:
Each deletion requires confirmation:
Fragments of balancing tree can also be cut and pasted:
Choose where to paste the cut fragment:
Result:
Parts of a balancing tree can be copied in a similar way as well:
Tap on Copy node.
Choose where to paste the copied fragment:
Result:
The same process can be repeated for the last part of the balancing tree:
Result:
Import And Export
You can import and export your balancing tree:
Balancing tree file is generated in xml and has the following structure:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<strategy>
<projectId>4947</projectId>
<projectDisplayName>Recur AUD</projectDisplayName>
<routingNodes>
<routingNode>
<id>8572</id>
<routingId>1</routingId>
<enabled>true</enabled>
<routes>
<route>
<id>23277</id>
<enabled>true</enabled>
<nextRoutingNodeId>8573</nextRoutingNodeId>
<others>true</others>
<criteria>
<criterion>
<value>OTHERS</value>
</criterion>
</criteria>
<order>0</order>
</route>
</routes>
<root>true</root>
</routingNode>
<routingNode>
<id>8573</id>
<routingId>2</routingId>
<enabled>true</enabled>
<routes>
<route>
<id>23279</id>
<enabled>true</enabled>
<nextRoutingNodeId>8574</nextRoutingNodeId>
<others>false</others>
<criteria>
<criterion>
<entityId>8104</entityId>
<entityName>213100</entityName>
</criterion>
</criteria>
<order>0</order>
</route>
<route>
<id>23278</id>
<enabled>true</enabled>
<others>true</others>
<criteria>
<criterion>
<value>OTHERS</value>
</criterion>
</criteria>
<order>1</order>
</route>
</routes>
<root>false</root>
</routingNode>
<routingNode>
<id>8574</id>
<routingId>3</routingId>
<enabled>true</enabled>
<routes>
<route>
<id>23281</id>
<enabled>true</enabled>
<nextRoutingNodeId>8575</nextRoutingNodeId>
<others>false</others>
<criteria>
<criterion>
<entityId>1825</entityId>
<entityName>DEMO BANK</entityName>
</criterion>
</criteria>
<order>0</order>
</route>
<route>
<id>23280</id>
<enabled>true</enabled>
<others>true</others>
<criteria>
<criterion>
<value>OTHERS</value>
</criterion>
</criteria>
<order>1</order>
</route>
</routes>
<root>false</root>
</routingNode>
<routingNode>
<id>8575</id>
<routingId>4</routingId>
<enabled>true</enabled>
<routes>
<route>
<id>23282</id>
<enabled>true</enabled>
<balancingNodeId>8750</balancingNodeId>
<others>true</others>
<criteria>
<criterion>
<value>OTHERS</value>
</criterion>
</criteria>
<order>0</order>
</route>
</routes>
<root>false</root>
</routingNode>
</routingNodes>
<balancingNodes>
<balancingNode>
<id>8750</id>
<enabled>true</enabled>
<balancingId>1</balancingId>
<rows>
<row>
<id>0</id>
<enabled>false</enabled>
</row>
</rows>
</balancingNode>
</balancingNodes>
</strategy>