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 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.
card range 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
  1. 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.
sccs 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 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.
card range dest 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 card and build a further route based on them.
pic21 balancing 2.0
  1. 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.
rccs 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 balancing 2.0
  1. by purpose routing type allows to sort transactions based on purpose.
purpose balancing 2.0

Transaction

  1. 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.
amount 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
  1. 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.
multiplicity balancing 2.0
  1. 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].
time 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.

  1. Chain by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status and the chain principle.
pic59 balancing 2.0

All client transactions (defined by card) 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

  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.

  1. First in Sequence by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status.
pic58 balancing 2.0

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.

  1. First in Sequence by Last Customer Tx Status on Gate allows to sort transactions by resulting transaction status.
pic58 balancing 2.0

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.

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 (Gate and Processor levels).

Gate level

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

Warning

If filter on the gate is triggered, this gate is removed from balancing block for the current transaction.

Information and reason codes about gates which were excluded from balancing due to triggered filters is displayed in transaction details on UI:

pic51 balancing 2.0

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

There are such filters as:
Filter Name Comment UI code
Whitelist check (WL) Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for: the exact Source card number by manager, the exact Device fingerprint by manager.  
Predefined loyalty lists check Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out.. 15034,15035,15036,15037
Automatic loyalty lists check This filter allows to specify a set of gates (“group name”) and create subsets of gates (“financial instruments”) within this set scope to allow processing of transactions with card numbers only on linked subsets of gates. Each card number which is processed by one of the gates within the set (“group name”) for the first time is linked to the subset (“financial instrument”) of the gate used for processing. All new transactions with the same card number will be allowed to process only on gates with the linked “financial instrument” and filtered on all other gates with different “financial instruments” within the same “group name” set. If the “group name” or “financial instrument” is not indicated on the gate, this filter will not be applied (even if it’s enabled). 15110
Source Credit Card Number usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15004,15005
Source Credit Card Number usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15002,15003
Source Credit Card Number usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 15000,15001
Source Credit Card Number usage frequency for last 3 months This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in the approved status. 15075,15076
Source Credit Card Number usage frequency for last 6 months This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in the approved status. 15077,15078
Source Credit Card Number usage frequency for last 12 months This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in the approved status. 15079,15080
Purpose usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15016,15017
Purpose usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15014,15015
Purpose usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 15012,15013
Email usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15010,15011
Email usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 15008,15009
Email usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 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 13 calendar days from the date of the original decline response for the same acquirer if the response code is one of the following:

  • Response Code 05-Authorization Declined
  • Response Code 51-Insufficient Funds
  • Response Code 61-Exceeds Approval Amount Limit
  • Response Code 65-Exceeds Withdrawal Frequency Limit

If an approval response is not received within this time frame, merchants must not resubmit the transaction or their acquirers may be subject to non-compliance actions, as outlined in the Visa Rules, and may be subject to chargebacks. Visa Rules to prohibit acquirers and their recurring services merchants from resubmitting a declined transaction for authorization if it receives a pickup response:

  • Response Code 04-Pick Up Card
  • Response Code 07-Pick Up Card, Special
  • Response Code 33-Expired Card, Capture
  • Response Code 34-Suspected Fraud, Retain Card
  • Response Code 35-Card Acceptor, Contact Acquirer, Retain Card
  • Response Code 36-Restricted Card, Retain Card
  • Response Code 37-Contact Acquirer Security Department, Retain Card
  • Response Code 41-Lost Card
  • Response Code 43-Stolen Card
  • Response Code 67-Capture Card

or a decline response of

  • Response Code 14-Invalid Account Number (No Such Number)
  • Response Code 54-Expired Card
  • Response Code 57-Transaction Not Permitted.

The time threshold is a moving window calculated backwards from the moment of the transaction. Counts Account verification, Sale, Preauth or Transfer transactions in Declined status for listed decline reasons. Correct decline reasons should be supported by a connected PSP. Limits are calculated separately per gate descriptor and not per gate.

15023,15024 - CANCEL,15025 - PICKUP,15026 - DELAY
Entire Email usage frequency for last 24 hours (entire daily limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. 15042,15043
Entire Email usage frequency for last 7 days (entire weekly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. 15044,15045
Entire Email usage frequency for last month (entire monthly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. 15046,15047
Entire Purpose usage frequency for last 24 hours (entire daily limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. 15048,15049
Entire Purpose usage frequency for last 7 days (entire weekly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. 15050,15051
Entire Purpose usage frequency for last month (entire monthly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. 15052,15053
Entire Source Credit Card Number usage frequency for last 24 hours (entire daily limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. 15054,15055
Entire Source Credit Card Number usage frequency for last 7 days (entire weekly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. 15056,15057
Entire Source Credit Card Number usage frequency for last month (entire monthly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. 15058,15059
Entire Source Credit Card Number usage frequency for last 3 months (entire 3 months limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in any status. 15081,15082
Entire Source Credit Card Number usage frequency for last 6 months (entire 6 months limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in any status. 15083,15084
Entire Source Credit Card Number usage frequency for last 12 months (entire 12 months limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in any status. 15085,15086
Source Credit Card Number usage frequency for Destination Credit Card Number This check fires when the number of Source Credit Cards associated with exact Destination Credit Card number exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Transfer transactions in approved or declined status for the current Gate. 15072
Declined Email usage frequency for last 24 hours (decline daily limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in declined status. 15066
Declined Email usage frequency for last 7 days (decline weekly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status. 15068
Declined Email usage frequency for last month (decline monthly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in declined status. 15070
Source Credit Card Number decline frequency for last 24 hours (daily decline limit)

This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined or Filtered status.

Parameters available in this filter:

  • amount limit - Maximum total transactions amount for the last 24 hours for this credit card used as Source card for all gates with the same descriptor.
  • quantity limit - Maximum total transactions count for the last 24 hours for this credit card used as Source card.
15073, 15074

Example of configuration “Email usage frequency for last month (monthly limit)” filter. To switch this filter on, click on the toggle button near it’s name:

emailusage balancing 2.0

This filter supports the following settings:

  1. The Amount limit maximum total transactions amount for the last one month for this e-mail address. Value: total amount value.
  2. For all gates with the same descriptor – current total transactions amount or count for the last one month for this e-mail address value would be calculated and converted to current gate currency to compare with amount or quantity limit. Specify the value “Y” (Yes) instead of “N” (No) to enable. Values: Y: for all gates with the same descriptor, N: for current gate only.
  3. The quantity limit parameter specifies the transactions quantity limits. Value: total quantity value.
  4. Use calendar month : Value: Y/N.

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.

Processor level

Filters, can be configured on the processor level to affect all gates of this processor. To switch them on, go to the required processor and click on the “Acquirer restrictions” tab. Tab will be available only for manager account and linked superiors.

Processor ACQ tab
There are such restrictions as:
Filter Name Comment UI code and reason
Whitelist check (WL) Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for: the exact Source card number by manager, the exact Device fingerprint by manager.  
Predefined loyalty lists check Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out.. 18042 if Proccessor loyal source card number check failed, 18043 if Proccessor loyal destination card number check failed
Source Credit Card Number usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18004 if Approved hourly amount limit reached, 18005 if Approved hourly quantity limit reached
Source Credit Card Number usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18002 if Approved weekly amount limit reached, 18003 if Approved weekly quantity limit reached
Source Credit Card Number usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 18000 if Approved monthly amount limit reached, 18001 if Approved monthly quantity limit reached
Destination Credit Card Number usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions only in the approved status. 18032 if Destination approved hourly amount limit reached, 18033 if Destination approved hourly quantity limit reached
Destination Credit Card Number usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions only in the approved status. 18030 if Destination approved weekly amount limit reached, 18031 if Destination approved weekly quantity limit reached
Destination Credit Card Number usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions only in the approved status. 18028 if Destination approved monthly amount limit reached, 18029 if Destination approved monthly quantity limit reached
Total Credit Card Number usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18038 if Total approved hourly amount limit reached, 18039 if Total approved hourly quantity limit reached
Total Credit Card Number usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18036 if Total approved weekly amount limit reached, 18037 if Total approved weekly quantity limit reached
Total Credit Card Number usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 18034 if Total approved monthly amount limit reached, 18035 if Total approved monthly quantity limit reached
Email usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18010 if E-mail approved hourly amount limit reached, 18011 if E-mail approved hourly quantity limit reached
Email usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18008 if E-mail approved weekly amount limit reached, 18009 if E-mail approved weekly quantity limit reached
Email usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 18006 if E-mail approved monthly amount limit reached, 18007 if E-mail approved monthly quantity limit reached
Email usage lifetime Allows to limit the number and amount of transactions available to an individual customer and set a limit on the processor for the ALL time of existence. Customer is determined by E-Mail. This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time period is lifetime. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction. Counts Sale, Preauth or Transfer transactions in the approved status. 18048 if E-mail approved lifetime amount limit reached, 18049 if E-mail approved lifetime quantity limit reached
Customer IP usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18022 if Customer IP approved hourly amount limit reached, 18023 if Customer IP approved hourly quantity limit reached
Customer IP usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18020 if Customer IP approved weekly amount limit reached, 18021 if Customer IP approved weekly quantity limit reached
Customer IP usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 18018 if Customer IP approved monthly amount limit reached, 18019 if Customer IP approved monthly quantity limit reached
Purpose usage frequency for last 24 hours (daily limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18016 if Purpose approved hourly amount limit reached, 18017 if Purpose approved hourly quantity limit reached
Purpose usage frequency for last 7 days (weekly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. 18014 if Purpose approved weekly amount limit reached, 18015 if Purpose approved weekly quantity limit reached
Purpose usage frequency for last month (monthly limit) This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. 18012 if Purpose approved monthly amount limit reached, 18013 if Purpose approved monthly quantity limit reached

3.9.8. Copy, paste, cut, 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

Parts of a balancing tree can be copied in a similar way as well:

pic40 balancing 2.0

3.9.9. Import and export

You can import and export your balancing tree:

pic40 balancing 2.0

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>VTB 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>