Routing configurations enable the management of payment flows, ensure compliance, and optimize processing performance, all while maintaining flexibility and control over their payment infrastructure.

With a no-code, customizable platform, you can scale quickly to new geographies, improve payment conversion rates, and diversify risk.


Routing flow

Routing configuration is set up for a channel with the payment method level. This allows operators to manage and optimize payment traffic across multiple payment methods, such as Cards and Digital wallets, Apple Pay and Google Pay.

Each channel corresponds to a product, website, or store. To process payments at the same time, one account can have several channels.


Routing components

Routing configurations consist of several components, each essential for directing and optimizing payment traffic.

  • Rule preset sets initial conditions, like blocking payments or enforcing 3DS.
  • Rules define how payments are routed based on parameters and logic operators.
  • Splits distribute payment traffic across connector accounts.
  • Segments configure the processing sequence for payments, including fallbacks.

Rule preset

Rule presets are evaluated before routing rules are applied, ensuring that specific criteria are met before proceeding with the transaction.

Presets are evaluated from top to bottom, with the first matching condition taking precedence over subsequent ones. Each configuration type has its own rule presets. Key condition:

  • Block payments
    Blocks certain payments. If triggered, the transaction is declined with the decline code 0.04 Payment processing unavailable.
  • Force 3DS
    Determines whether payment processing rules fall under force 3DS. This preset applies to all payments that antifraud system has identified as force 3DS, or provided force3ds true through the Solidgate API .
    • SCA regulation
      A European rule to reduce fraud in online and contactless payments.
    • Low-value SCA exemption
      Allows low-value transactions to skip SCA under PSD2.
    • TRA SCA exemption transaction handling
      Permits low-risk transactions to bypass SCA, reducing friction.
    • Non-3DS for MIT/MOTO
      3DS can often be bypassed or handled differently than standard online payments.
  • Other PAN only
    Specifies that only payments involving other PANs are allowed.
  • All other payments
    Applies to all payments not otherwise categorized by the specific routing presets.

For the Digital wallets payment method, Force 3DS with Other PAN only is included in the Google Pay PAN only preset. This ensures that transactions are routed and processed only for Google Pay PANs with 3DS enforcement.

Each rule preset, except Block payments, includes a Default branch that must be completed. You cannot add rules to the Default branch, as it serves as the base setting. You can configure other branches as needed.


Rules

Routing rules are the core logic that defines how payments are routed through different payment processors (PSPs). These rules consist of parameters and values that can be combined using logical operators.

Rules condition:

  • Can be as simple or complex as necessary, with condition nesting supported up to 3 levels.
  • Work top-down by priority, meaning that if a payment matches the first rule, it follows that path, and further rules are not checked. Similarly, conditions within a rule operate in the same way.
Parameters
  • Amount USD - represents the total amount of the order.
  • Bank - refers to the name of the bank associated with the transaction.
  • BIN - defines a list of BINs used for routing based on specific patterns.
  • BIN country - defines the country associated with the BIN.
  • Card brand - used for the transaction, such as Visa, Mastercard, or other supported brands.
  • Card type - specifies the type of card being used.
  • Country - specifies the country associated with the customer or transaction for geographic routing.
  • Currency - specifies the currency of the order.
  • Customer account ID - specifies a unique identifier assigned to the customer's account for tracking.
  • Customer email - specifies the email address associated with the customer for communication and transaction purposes.
  • Data origin - specifies the origin of the data used in the transaction.
  • External MPI - allows for the configuration of conditions based on the presence of external MPI data.
  • Fraud risk detected - specifies whether a fraud risk has been detected in the transaction.
  • Initiator origin - specifies the origin of the transaction initiator.
  • IP address - specifies the IP address of the device used to initiate the transaction.
  • Order amount - represents the total amount of the transaction in the original currency.
  • Payment method type - defines the type of payment method being used.
  • Traffic source - helps identify where the traffic is coming from.
  • Website - specifies the website where the transaction is originating from.
For the metadata rule, you can enter any metadata parameter that corresponds to its respective data type and value. Logic operators
  • Equal - must exactly match the specified value.
    Card brand = Visa
  • Greater than - must be greater than the specified value.
    Amount > 100
  • Greater than or equal - must be greater than or equal to the specified value.
    Amount ≥ 100
  • Less than - must be less than the specified value.
    Amount < 100
  • Less than or equal - must be less than or equal to the specified value.
    Amount ≤ 100
  • Not equal - must not match the specified value.
    BIN country ≠ US
  • Not one of - must not match any value from a provided list.
    Card type not in [Credit, Debit]
  • One of - must match any value from a provided list.
    Website = one of [site1.com, site2.com]
Depending on the type of parameter, the available logic operators may vary.

Splits

Splits define how payment traffic is distributed across different connector accounts.

  • Each split is assigned a percentage of traffic, and each group block of rules requires a separate split.
  • Sum of all segments in a group must equal 100%.
  • Maximum of 20 groups can be defined for a single rule.

Segments

Configuring a segment involves setting up the sequence of steps for a split group.

The list of available options depends on the connector itself, making it flexible and adaptable to the specific configuration of the connector account. Additionally, display whether the connector account supports the acceptance of External MPI Data.

  • A maximum of 5 steps can be defined in a group. They can be the same, but the features and descriptors must differ.
  • Fallbacks are not available on the Force 3DS branch.

For each segment, it is essential to ensure that the features/descriptors vary, even if the same connector account is used multiple times.

Steps allow fallback routing, directing traffic to MIDs when the initial route fails. Each step level is evaluated in sequence, providing up to 5 levels of fallback routing. Use steps for retry strategies after declines or failures to ensure continuous payment processing.

Stop error codes prevent transactions from proceeding to the next step. These errors indicate fundamental issues with the card, account, or transaction that cannot be resolved by routing to an alternative processor.

Attempting retries would result in the same failure regardless of the payment gateway used, while unnecessarily increasing processing costs and delaying the final response to the customer.

Stop error codes
  • 0.02 Order expired
  • 2.06 Invalid CVV2 code
  • 2.08 Invalid card number
  • 2.09 Invalid expiration date
  • 3.02 Insufficient funds
  • 3.12 Closed account
  • 4.01 Card is on blacklist
  • 4.02 Stolen card
  • 4.04 Lost card
  • 4.07 Trusted antifraud system