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:
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
- A new configuration starts as Inactive .
- After testing, set the status to Active and publish. The version becomes Live .
- 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.
Force 3DS
currency = EUR
70% / 30%
Connector Account A + Descriptor X + Feature Y enabled
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:
Preset definitions:
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.
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:
- 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.
-
Guide
The Card Verification Value (CVV2) provided does not match the card's security code. 2.06 Invalid CVV2 code -
Guide
The card number entered is not valid or does not exist. 2.08 Invalid card number -
Guide
The expiration date provided for the card is incorrect or the card has expired. 2.09 Invalid expiration date -
Guide
The next subscription or a 1-click payment using a recurring token via this payment method is not allowed. 3.11 Recurring payment cancelled -
Guide
The account associated with the card has been closed and cannot be used for transactions. 3.12 Closed account -
Guide
The payment card being used is listed on a security blocked list, often due to prior suspicious or fraudulent activities. 4.01 Card is on blocklist -
Guide
The card in use has been reported as stolen, all transactions are restricted. 4.02 Stolen card -
Guide
The card has been reported as lost and is blocked from processing any transactions. 4.04 Lost card -
Guide
The transaction was blocked by a trusted antifraud system due to suspicious activity or high-risk indicators. 4.07 Trusted antifraud system -
Guide
An invalid or nonexistent card token was received during the transaction. 5.02 Invalid card token -
Guide
Processing error; ask the customer to try again or use another card. 5.08 Invalid transaction -
Guide
The card token is missing or inaccessible, so saved card payments cannot proceed until credentials are re-entered. 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:
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.