3.9. Routing & Balancing

3.9.1. 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:

pic1 balancing 2.0

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:

pic2 balancing 2.0

Hover the cursor over the name of this block to select one of the following actions:

k
f - Add routing row - to add options for this block
e - 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:

a - Continue Routing - to select new routing block and continue the routing strategy.
l
b - Add balancing - to stop the routing and add the balancing block.
m
c - to enable, disable or delete the routing option.
n

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 b 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:

pic8 balancing 2.0

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:

g - Add balancing row - adds the row with active fields to specify the gate:
v
  • 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.
e - Delete node - to select another routing or balancing block instead of this one.
w
h - Create group - to create a group of the balancing.
x
pic9 balancing 2.0

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:

pic10 balancing 2.0

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. 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”.

pic11 balancing 2.0

Now, the Routing & Balancing is applied and all the traffic will go through it.

3.9.2. 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

  1. 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.
pic12 balancing 2.0
  1. The Source Card BIN routing type allows to sort transactions by the sender’s card BIN value. Select the needed BIN values of the sender and build a further route based on them.
pic13 balancing 2.0
  1. 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.
pic14 balancing 2.0
  1. 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.
pic15 balancing 2.0
  1. The Source Card Level routing type allows to sort transactions by the sender’s card Level. Select the needed level’s of the sender and build a further route based on them.
pic16 balancing 2.0

Destination Card

  1. 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.
pic17 balancing 2.0
  1. The Destination Card BIN routing type allows to sort transactions by the receiver’s card BIN value. Select the needed BIN values of the receiver and build a further route based on them.
pic18 balancing 2.0
  1. 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.
pic19 balancing 2.0
  1. 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.
pic20 balancing 2.0
  1. The Destination Card Level routing type allows to sort transactions by the receiver’s card level. Select the required card level’s of the receiver and build a further route based on them.
pic21 balancing 2.0

Customer

  1. 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.
pic22 balancing 2.0
  1. 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.
pic23 balancing 2.0
  1. 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.
pic24 balancing 2.0

4. Customer Loyalty routing type is divided into endpoint, project, merchant. Each of these levels has a return_customer_approve_sessions_count field where can set a value for the “RETURNING” parameter. 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 the endpoint settings, you can set the parameters by which the client will be definited. This option is called Client definition. Definition by card number, card holder and email, card holder and purpose, card holder and phone.

pic25 balancing 2.0
  1. by Recurring and Non_recurring routing types allows to sort transactions based on whether transaction type is recurrent or not.
pic28 balacncing 2.0

Transaction

  1. Transaction Amount routing type allows to sort transactions by their amounts. Transactions, which amounts match the specified range, will pass through this routing criterion.
pic26 balancing 2.0
  1. Transaction Type routing type allows to sort transactions by their type. Select the needed transaction types and build a further route based on them.
pic27 balancing 2.0

Transfer

  1. 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.
pic28 balancing 2.0

3.9.3. 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

  1. Balance by coefficient Based on Tx Amount allows to sort transactions by the gates depending on the amount and the specified probability percentage.
pic29 balancing 2.0

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.

  1. Balance by coefficient Based on Tx Count allows to sort transactions by gates depending on their quantity and the specified probability percentage.
pic30 balancing 2.0

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

  1. Balance equally Based on Tx Amount allows to sort transactions by gates depending on the amount with equal probability percentage.
pic31 balancing 2.0

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.

  1. Balance equally Based on Tx Count allows to sort transactions by gates depending on the quantity with equal probability percentage.
pic32 balancing 2.0

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

  1. 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.
pic33 balancing 2.0

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.

  1. 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.
pic34 balancing 2.0

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.

  1. Chain by Sequence allows to sort transactions using the cascading chain principle.
pic35 balancing 2.0

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.

Others

  1. First in Sequence allows to sort transactions by choosing the first appropriate gate for them.
pic36 balancing 2.0

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.

3.9.4. Chain strategy details

Chain strategy details allows to select which Declines (negative processing results) will continue or stop the chain.

If the configured routing has such balancing types as: Chain by Sequence, Chain by Equivalently on Tx Count, Chain by Coefficient on Tx Count, it’s possible to go to the “Chain Strategy Details” tab on the gate level and select the criteria to continue or stop the chain.

pic37 balancing 2.0

The number and name of the gate is at the top of the page. The active line “Continue the chain” is located below and the choice of criteria is to the right of it. “Independently of the decline reason” is selected by default.

Two active columns – “Unavailable” and “Available” – are located below. The reasons for decline are located in the “Unavailable” field. The chain can continue:

  • Independently of the decline reason - the chain will continue regardless of the received decline codes.
  • Only for the selected decline reasons - the chain will continue only for the specified decline reasons. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.
  • For any decline reason except the selected ones - the chain will continue for all reasons, EXCEPT for the specified ones. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.

3.9.5. Chain strategy skips

Chain strategy skips allows to skip a gate for a specific transaction if one of selected errors occur (set in error codes) for a previously specified period of time(set in minutes).

chainstrat balancing 2.0

3.9.6. 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 the gate, project or endpoint level.

pic38 balancing 2.0

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.

3.9.7. Filters and acquirer restrictions

Filters are the configurable sets of rules which allow to restrict the traffic by certain criteria directly on the gate.

Filters, which are applied in the Routing & Balancing, can be configured on the gate level. To switch them on, go to the required gate and click on the “Acquirer restrictions” tab

pic39 balancing 2.0

There are such filters as:

Filter Name Comment UI code
Credit Card Whitelist check (WL) If source or destination credit card is in white list - no other gate filters will be applied.  
Loyalty lists check If customer’s data is not in one of the gate’s loyalty lists - filter declines transaction. 15034,15035,15036,15037
Check approved hourly limit If approved transactions amount or quantity during last 24 hours exceeds parameter values - filter declines transaction. 15004,15005
Check approved weekly limit If approved transactions amount or quantity during last week exceeds parameter values - filter declines transaction. 15002,15003
Check approved monthly limit If approved transactions amount or quantity during last month exceeds parameter values - filter declines transaction. 15000,15001
Check destination approved hourly limit If approved transactions amount or quantity during last 24 hours to one destination exceeds parameter values - filter declines transaction. 15016,15017
Check destination approved weekly limit If approved transactions amount or quantity during last week to one destination exceeds parameter values - filter declines transaction. 15014,15015
Check destination approved monthly limit If approved transactions amount or quantity during last month to one destination exceeds parameter values - filter declines transaction. 15012,15013
Check e-mail approved hourly limit If approved transactions amount or quantity during last 24 hours to one e-mail exceeds parameter values - filter declines transaction. 15010,15011
Check e-mail approved weekly limit If approved transactions amount or quantity during last week to one e-mail exceeds parameter values - filter declines transaction. 15008,15009
Check e-mail approved monthly limit If approved transactions amount or quantity during last month to one e-mail exceeds parameter values - filter declines transaction. 15006,15007
Visa Preauthorized Transaction Decline Response requirements This check fires for recurring transactions only. Merchants that receive a decline response for a preauthorized transaction will only be allowed to resubmit it for authorization up to four times within 16 calendar days from the date of the original decline response if the response code is one of the following: - Response Code 05. 15023,15024,15025,15026
Check e-mail entire hourly limit If entire (approved and declined) transactions amount or quantity during last 24 hours to one e-mail exceeds parameter values - filter declines transaction. 15042,15043
Check e-mail entire weekly limit If entire (approved and declined) transactions amount or quantity during last week to one e-mail exceeds parameter values - filter declines transaction. 15044,15045
Check e-mail entire monthly limit If entire (approved and declined) transactions amount or quantity during last month to one e-mail exceeds parameter values - filter declines transaction. 15046,15047
Check destination entire hourly limit If entire (approved and declined) transactions amount or quantity during last 24 hours to one destination exceeds parameter values - filter declines transaction. 15048,15049
Check destination entire weekly limit If entire (approved and declined) transactions amount or quantity during last week to one destination exceeds parameter values - filter declines transaction. 15050,15051
Check destination entire monthly limit If entire (approved and declined) transactions amount or quantity during last month to one destination exceeds parameter values - filter declines transaction. 15052,15053
Check entire hourly limit If entire (approved and declined) transactions amount or quantity during last 24 hours to one e-mail exceeds parameter values - filter declines transaction. 15054,15055
Check entire weekly limit If entire (approved and declined) transactions amount or quantity during last week to one e-mail exceeds parameter values - filter declines transaction. 15056,15057
Check entire monthly limit If entire (approved and declined) transactions amount or quantity during last month to one e-mail exceeds parameter values - filter declines transaction. 15058,15059
Min transaction amount If transaction amount is less than the parameter value - filter declines transaction. 15057
Max transaction amount. If transaction amount is more than the parameter value - filter declines transaction. 15019

Displays the UI Code of the filter in the balancing logs column. The filter rejected the transaction.

pic51 balancing 2.0

API response text for these filters can be found on PaynetEasy internal errors

To switch the required filter on, click the lamp symbol to the left of it. The filter setting will be available after the filter is switched on:

pic40 balancing 2.0

The following parameters will be available in the filters configurations of the “Check e-mail entire monthly limit” type :

  1. The Allowable transaction amount parameter specifies amount limits.
  2. For all gates with the same descriptor – the filter will be extended to all the gates with the same descriptor. Specify the value “Y” (Yes) instead of “N” (No) to enable.
  3. The Allowable number of transactions parameter specifies the transactions quantity limits.
  4. Ignore filtered transactions : N - not ignore filtered type transactions, Y - ignore filtered type transactions.
  5. Use calendar month : N - use 30 days as a period for the filter, Y - use a calendar month as a period for the filter.

The choice of “Country Identifier” will be available in the “Deny” filter configurations.

Each country is assigned its own numerical identifier. The required country can be chosen from the list.

3.9.8. Cut, paste, delete

Routing & balancing nodes can be deleted, along with all children:

pic40 balancing 2.0

Each deletion requires confirmation:

pic40 balancing 2.0

Fragments of balancing tree can also be cut and pasted:

pic40 balancing 2.0

Choose where to paste the cut fragment:

pic40 balancing 2.0

Result:

pic40 balancing 2.0