Routing

1. Introduction

A routing rule directs (or "routes") payments to specific payment methods based on conditions you define. By configuring routing logic, you can ensure that transactions meeting certain criteria (e.g., BIN, email, transaction amount, or country) are automatically directed to the most suitable or cost-effective payment channel.

Each rule consists of two parts:

• Conditions (sub-rules) — what transaction data to check and how to compare it.
• A routing target (Route to) — either a manual selection of your shop's connected payment methods, or automatic selection by success rate.

Key benefits of routing rules

• Cost optimization — route specific transactions to the payment provider offering the most favorable fees for that transaction type, currency, or region.
• Higher approval rates — different providers may have varying approval rates depending on a card issuer's country, currency, or transaction amount.
• Load balancing — distribute transaction volume across multiple payment providers to avoid capacity issues or downtime.
• Regional preferences — some payment methods may be more popular (or legally required) in certain countries or regions.

2. Where routing rules are managed

Routing rules are managed per shop: Merchant Account → Shops → your shop → Routing tab. The tab lists the shop's rules with their ID, type (Purchase or Payout), name, status, and the IDs of the payment methods the rule routes to. Use the type filter above the list to switch between purchase and payout rules.

Whether and when the rules are applied to a payment is controlled by the First attempt settings of the shop — see Payment Flow for the full selection logic. In short:

• Use routing — rules are evaluated when the order is created.
• Use payment page — rules are evaluated after the payer's choice on the payment page, and only if that choice does not already identify a single payment method. If no rule matches, the payment is processed with the first method in the shop's list that matches the selected option.
• Use request parameters only — routing rules are not evaluated; the request parameters must identify the method, otherwise the order fails. The method selection step is not shown in this mode.

Conditions that depend on payer input (currently the BIN) can only be evaluated after the payer enters the card number on the payment page — they are unknown at order creation time.

3. Creating a routing rule

Click Create rule on the Routing tab. The rule form contains the following sections:

1. Specify type
   • Type — whether the rule applies to purchases or payouts.
2. Add name
   • Rule name — a short, descriptive name that helps you recognize the rule in the list.
   • Description (optional) — additional context or notes.
3. Create sub-rules
   • The conditions under which the rule applies (see Defining sub-rules).
4. Route to
   • The payment methods that will process the matching transactions (see Selecting the routing target).
5. Buttons
   • Cancel — closes the form without saving.
   • Create rule — saves the new rule. New rules are created enabled.

4. Defining sub-rules (conditions)

Each sub-rule is a block of parameter comparisons. A comparison row consists of:

1. Parameter — what transaction data to check:

   Parameter	Meaning
   BIN	Bank identification number — the first 6–8 digits of the card. Evaluated after the payer enters the card number
   Card ID	Identifier of a saved card (cardId in the order request)
   Email	The payer's email address passed in the order request
   Payment amount	The order amount; the comparison is defined together with a currency
   Issue country	The card issuer's country
   Customer country	The customer's country from customer.details.addressData.countryCode in the order request (ISO 3166-1 alpha-2)
   Affiliate ID	The affiliate identifier passed in the order request
   IP country	The payer's IP geolocation country
   Transactions	Total transaction count or sum

2. Comparison operator — the available operators depend on the parameter. For Payment amount: =, !=, >, <, >=, <=, and Interval (a from–to amount range with inclusive bounds). The currency of an amount condition is always compared with = — this operator cannot be changed.

3. Value — the value to compare against. An amount condition is always paired with a currency comparison. For list parameters such as BIN, the Values field accepts several values in one condition — the condition matches when the entered card starts with any of the listed BINs. Use real BINs: a value the platform's BIN directory does not recognize may not match even when the card number starts with those digits.

Use Add parameter to add more comparisons to the same sub-rule: all parameters within one sub-rule must be satisfied together (AND). For example, a single sub-rule can require Payment amount >= 500 and Currency = EUR at the same time.

Use Add sub-rule to add an alternative block of conditions. Sub-rules are combined with OR (the blocks are joined with an "OR" divider in the form): the rule triggers if any of its sub-rules is satisfied.

5. Selecting the routing target

The Route to section defines where the matching transactions go. Two options are available:

• Select payment methods manually — select one or more of the shop's connected payment methods. Click Select payment methods (or Change payment methods when editing), select the methods, and apply the selection. Reset selection clears the current choice so you can switch to the other option. A rule may point to a currently disabled payment method — the list marks such a rule with a warning icon next to the method ID, and the rule cannot select that method until it is enabled again.
• Route by success rate — instead of a fixed method, the system automatically selects the payment method with the highest success rate.

The number of manually selected methods matters in Use routing mode:

• One payment method — when the rule matches, the method is selected automatically and the payer is taken directly to its data entry form.
• Several payment methods — such a rule never selects a method at order creation: the evaluation skips it and continues down the list. If no later rule resolves to a single method, the outcome depends on the Fallback to payment page setting, so for Use routing mode point each rule at a single method.

See Payment Flow for the full behavior, including what happens when no rule matches.

6. Rule priority

Rules are evaluated in list order — the first matching rule that resolves to a single payment method is applied, regardless of how many conditions each rule has. Use the Reorder function (the button appears above the list when the shop has more than one rule) to arrange the rules and place the most important ones at the top.

Saving changes to an existing rule can move it to the end of the list, and a newly created rule does not always land at the end. Since the position defines the priority, re-check the rule order after creating or editing a rule.

7. Managing existing rules

The menu at the end of a rule row provides:

• Edit rule — opens the same form as rule creation. Changes are versioned: the rule's change history is available on the History tab of the rule details. Editing does not change the rule's enabled/disabled state, but may move the rule to the end of the list (see Rule priority).
• Disable / Enable — temporarily turns the rule off or back on (with a confirmation dialog). A disabled rule never matches: with Use routing and disabled Fallback to payment page, orders that relied on this rule will fail (see Payment Flow).
• Delete — permanently removes the rule (with a confirmation dialog); a deleted rule cannot be restored.

Clicking a rule row opens a read-only panel with the rule details: type, conditions, target payment methods, and the change history.