Routing configurations manage payment flows, support compliance, and improve processing performance with flexible control over payment infrastructure.

With a no-code platform, you can expand to new markets, raise conversion, and diversify risk.


Routing flow

Routing is configured per channel and payment method. Operators can manage traffic for methods such as Cards and Digital wallets, including Apple Pay and Google Pay.

Each channel maps to a product, website, or store. One account can run several channels in parallel.


Routing components

Routing configurations use these components:

  • Rule preset sets initial conditions such as blocking payments or enforcing 3DS.
  • Rules define paths by parameters and logic operators.
  • Splits distribute traffic across connector accounts.
  • Segments set the processing sequence and fallbacks.

Rule preset

Rule presets run before routing rules. The first matching preset wins.

Presets are checked top to bottom. Each configuration type has its own presets:

  • Block payments
    Blocks matching payments. Decline code 0.04 Payment declined by routing rules.
  • Force 3DS
    Applies when antifraud marks force 3DS or the request sends force3ds true through the Solidgate API v1 .
    • SCA regulation
      European rule to reduce fraud in online and contactless payments.
    • Low-value SCA exemption
      Lets low-value transactions skip SCA under PSD2.
    • Auto-Force 3DS for Maestro
      Maestro usually requires 3DS by scheme rules. Disable only if your connector supports non-3DS Maestro and you will configure it manually. Enabled by default. When on, Maestro traffic goes to Force 3DS evaluation and avoids silent declines on non-3DS connector accounts.
    • Non-3DS for MIT/MOTO
      Allows non-3DS handling for MIT or MOTO where scheme rules allow it.
  • Other PAN only
    Limits the path to other PAN payments.
  • All other payments
    Covers traffic not matched by the presets above.

For Digital wallets, Force 3DS with Other PAN only sits under the Google Pay PAN only preset. Matching traffic is routed for Google Pay PANs with 3DS enforcement.

Each rule preset except Block payments includes a required Default branch. You cannot add rules to Default. Configure other branches as needed.


Rules

Routing rules define how payments move across payment processors. Rules combine parameters and values with logical operators.

Rules conditions:

  • Can be simple or nested up to 3 levels.
  • Run top-down by priority. The first match wins and later rules are skipped. Conditions inside a rule follow the same order.
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 reloadable - specifies whether the card belongs to a reloadable prepaid program.
  • 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.
  • 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 100 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
  • 2.06 Invalid CVV2 code
  • 2.08 Invalid card number
  • 2.09 Invalid expiration date
  • 3.11 Recurring payment cancelled
  • 3.12 Closed account
  • 4.01 Card is on blocklist
  • 4.02 Stolen card
  • 4.04 Lost card
  • 4.07 Trusted antifraud system
  • 5.02 Invalid card token
  • 5.08 Invalid transaction
  • 7.01 Card token not found