Help Center

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 group. The payment method group is based on the payment method data that the merchant passes to Solidgate, or that Solidgate collects through a payment link or payment form:

Cards

Typical card data that contains a card number (PAN). This covers cards with CVV, CoF payments, and mail order or telephone order (MOTO).

Digital wallets

Apple Pay and Google Pay.

Merchant Managed Network Tokens

Device primary account numbers (DPANs) stored outside Solidgate, such as network tokens or stored Apple Pay and Google Pay credentials.

Solidgate Tokens

If you use Solidgate tokenization, you define how the data stored under that token is managed.

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

Configuration statuses

A configuration is the main routing entity. You can create and manage multiple configurations per channel and payment method group. Only one configuration can be active and process payments at a time.

Configuration

Versions simplify change management. Each state of a routing configuration is stored as an immutable, identified version. A configuration has at most one draft version and one live version at any time.

Publishing freezes a version permanently. You can therefore compare, audit, and roll back configurations without interrupting payment processing on the channel.

Version

Common flow

1. A new configuration starts as Inactive .
2. After testing, set the status to Active and publish. The version becomes Live .
3. Move an unused Inactive configuration to Archived . Restore it later to Inactive .

Routing components

Routing configurations use these components:

Container of routing logic, attached to a channel.

Conditions select which traffic the rule handles.

Traffic is divided into weighted segments.

Ordered connector attempts inside a segment.

Rule preset

Rule presets organize the primary routing flows within each payment method group. They run before routing rules, and the first match takes precedence.

Available presets per payment method group:

Card

• Block payments
• Force 3DS
• All other payments

Digital wallet

• Block payments
• Google Pay PAN Only
  • Force 3DS
  • Other PAN Only
• All other payments

Merchant Managed Network Token

• Block payments
• Force 3DS
• All other payments

Solidgate Token

• Block payments
• Reroute to other connector account
  • Force 3DS
  • Non-3DS
• Process within existing connector account
  • Force 3DS
  • Non-3DS

Preset definitions:

Block payments

Blocks matching payments.

0.04

Force 3DS

Simplifies 3DS management by evaluating these conditions in the following order:

• External MPI
  The merchant passed a 3DS object. Forces 3DS.
• Non-3DS for MIT or MOTO
  Allows non-3DS handling where scheme rules allow it. This is an exemption, not a force reason.
• Antifraud decision
  Enforces 3DS authentication. Forces 3DS.
• API flag
  force3ds: true received through the Solidgate API. Forces 3DS.
• Auto-Force 3DS for Maestro
  Maestro usually requires 3DS by scheme rules. This option is enabled by default, so Maestro traffic goes to Force 3DS evaluation and avoids silent declines on non-3DS connector accounts. Disable it only if your connector supports non-3DS Maestro and you configure it manually. Forces 3DS with reason maestro_card_brand.
• Low-value SCA exemption
  Lets low-value transactions skip strong customer authentication (SCA) under PSD2. This is an exemption, not a force reason.
• SCA regulation check
  European rule to reduce fraud in online and contactless payments. Forces 3DS.

Google Pay PAN Only

Manages cards stored directly in the user's Google Account rather than as a tokenized DPAN, per Google Pay and 3DS.

All other payments

Covers traffic not matched by the presets above.

Reroute to other connector account

Reroutes payments that match the rule conditions.

Process within existing connector account

Specifies whether the payment is processed through a custom payment flow or through the default recurring strategy within an existing connector account.

Cards, Digital wallets, Merchant Managed Network Tokens

To publish a configuration, every rule preset with a Default rule needs a fully configured route with both a split and a segment. The Default rule works as a fallback, so no payment is left without processing. Once that is done, you can configure any other rules as needed.

Solidgate Tokens

You can publish without a configured route here. The default recurring strategy keeps recurring payments running, and processes them in the connector account where the initial payment went through. Set up the default recurring strategy in connector account settings.

Rules

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

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

• Order amount
  Represents the total amount of the transaction in the original currency.
• Amount USD
  Represents the total amount of the order.
• Currency
  Specifies the currency of the order.
• Payment method type
  Defines the type of payment method being used.
• Card brand
  Used for the transaction, such as Visa, Mastercard, or other supported brands.
• Card type
  Specifies the type of card being used.
• Card reloadable
  Specifies whether the card belongs to a reloadable prepaid program.
• BIN
  Defines a list of BINs used for routing based on specific patterns.
• BIN country
  Defines the country associated with the BIN.
• DPAN Source
  Defines the source of the DPAN for Merchant Managed Network Tokens. Values are Apple Pay, Google Pay, VTS, MDES, and SCOF.
• External MPI
  Allows for the configuration of conditions based on the presence of external MPI data.
• Init DSRP
  Defines whether the initial payment was performed with a digital wallet, either Apple Pay or Google Pay.
• Country
  Specifies the country associated with the customer or transaction for geographic routing.
• IP address
  Specifies the IP address of the device used to initiate the transaction.
• Bank
  Refers to the name of the bank associated with the transaction.
• Website
  Specifies the website where the transaction is originating from.
• Traffic source
  Helps identify where the traffic is coming from.
• Data origin
  Specifies the origin of the data used in the transaction.
• Initiator origin
  Specifies the origin of the transaction initiator.
• 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.
• Initial Connector ID
  The connector of the initial payment.
• Initial Connector Account ID
  The connector account of the initial payment.
• Initial Descriptor
  The descriptor of the initial payment.

• 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]

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

A segment defines how a split routes its traffic. It consists of a cascade of steps, where each step can additionally have its own fallbacks.

Cascade

A cascade is an ordered sequence of steps. Steps are evaluated one by one until the transaction is successfully processed, the sequence ends, or a stop error code occurs.

Each step targets a connector account with a specific processing method and feature set. Moving from one step to the next changes the route, which makes the cascade the mechanism for retry strategies after declines or technical failures.

Cascade types:

Standard cascades

Cover card payments, Apple Pay, and Google Pay. Traffic cascades between steps according to the configured sequence.

3DS cascades

After a successful 3D Secure authentication, the same authentication result can be reused on cascade retries instead of running a new challenge on the next step. This keeps the liability shift while avoiding a second challenge for the customer.

• A segment can contain a maximum of 5 steps, which gives up to 5 levels of cascading.
• Every step must have a unique combination of features and descriptors, even when the same connector account is used more than once within the segment.

Stop error codes end the cascade and prevent the transaction from proceeding to the next step. They indicate a fundamental issue with the card, the account, or the transaction that a different route cannot resolve.

Retrying such a transaction would produce the same result regardless of where it is routed, while increasing processing costs and delaying the final response to the customer.

• 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

Steps and fallbacks

A step is a connector account combined with a specific processing method and feature set. The options available for each step depend on the connector itself, so the configuration always reflects the actual capabilities of the connector account.

Some declines do not require a different route. They require a different request on the same connector account, such as stepping up to 3D Secure or switching from a network token to raw card data. A fallback handles exactly this. It retries the transaction on the same connector account with a modified feature set, before the cascade moves on.

Fallbacks remove the need to add boilerplate retry steps by hand and apply proven recovery practices without requiring payments expertise.

Available fallbacks:

Soft decline fallback

When a non-3DS CIT payment is declined with a soft decline signal, the payment is automatically retried with 3DS enabled.

Stops cascade execution

TRA-to-3DS fallback

When a TRA-exempted payment is declined, the CIT payment is resubmitted with full 3DS instead of the exemption.

Stops cascade execution

Retry with initial connector account

Applies to Solidgate Tokens. Retries with a PSP token or Card-on-File on the initial connector account.

Cascade continues

Card fallback / Card-on-File fallback

Applies to Cards and Wallets, or Solidgate Tokens. Falls back to card payments, or to Card-on-File payments, if the network token is unavailable or declined.

Cascade continues

How fallbacks are applied:

• Fallbacks are configured per step and are disabled by default.
• A fallback inherits all settings from its parent step except the parameters it overrides.
• If several fallbacks match a failed attempt, they are applied in the order listed above. Only one fallback runs per attempt.
• If the fallback retry also fails, the cascade moves to the next step, unless the fallback is one that stops cascade execution.