Learn about PXP's Smart Routing service.
Smart Routing is an intelligent payment routing solution designed to optimise transaction success rates and reduce processing costs. It allows you to define granular routing logic based on pre-defined transaction parameters, directing traffic to the most appropriate and efficient acquirer in real time, maximising approval rates and driving greater revenue. This system enhances merchant control over payment performance, ensures fallback during acquirer outages, and supports scalable operations across regions and acquirers.
With Smart Routing, you can benefit from:
- Higher approval rates and reduced declines: Route payments to acquirers with the highest success rates for each transaction, using real-time performance data at Merchant Category Code (MCC) and acquirer levels to minimise failures.
- Optimised revenue and lower costs: Increase transaction volume and revenue through improved approval rates, while reducing overall processing costs through intelligent routing optimisation that considers performance, fees, and business strategy.
- Full customisation and business control: Create and manage routing logic tailored to your specific business needs, performance goals, and risk preferences.
- Intelligent decision making: Configure rules using comprehensive parameters including BIN, scheme type, amount, currency, and more to implement flexible outcome definitions for approval rate optimisation, volume splits, or specific acquirer routing.
- Resilient payment processing: Ensure uninterrupted transaction processing through automated downtime detection, real-time acquirer monitoring, seamless volume redirection during outages, and intelligent retry mechanisms.
- Real-time execution and monitoring: Get instant routing decisions with comprehensive performance visibility, enabling immediate identification of optimisation opportunities and continuous system improvement.
A rule is a single, atomic business logic statement that defines the conditional logic for routing decisions. A rule is grouped together with other rules to form a ruleset.
Each rule follows an IF-THEN-ELSE structure:
IF (conditions are met)
THEN (routing action)
ELSE (alternative routing action)- Parameters: What to evaluate (e.g.,
Amount,Intent) - Comparison operators: How to compare (e.g.,
equals,greater than) - Values: What to compare against (e.g.,
USD,Visa) - Logical operators: How to combine conditions (
AND,OR)
- Route transaction: Specify which providers to use
- Split volume: Whether to distribute traffic across multiple providers
- Use best approval rate: Whether to prioritise providers with highest success rates
For example:
A ruleset is a named collection of related rules that work together as a unified routing strategy and are evaluated in a specific sequence. You can create several rulesets, but only one ruleset can be active at any given time.
- Duplicate prevention: No two rules in a ruleset can have the same name.
- Activation control: Individual rules can be enabled/disabled within a ruleset.
- Versioning: Each rule tracks its version number and you can view a snapshot of each version.
- Testing cycle: Switch between rulesets for A/B testing without losing configurations.
- Inheritance context: Rulesets respect the owner hierarchy for conflict resolution.
You can configure rulesets for a wide variety of use cases, such as:
- Business policy sets: Rules for handling specific transaction types
- Geographic rules: Different routing strategies by country/region
- Risk-based rules: Enhanced routing for high-risk transactions
- Performance optimisation: Rules that adapt based on provider performance structure
Smart Routing implements a sophisticated hierarchical configuration model where settings cascade from specific owners down to broader organisational levels.
You can set up Smart Routing at the following organisational levels:
- Site level: Specific rules for individual locations or websites
- Merchant level: Rules for entire businesses
- Merchant group level: Shared rules across multiple merchants
Lower levels can override higher-level settings when needed (IsInherited = false).
For a transaction from ACME London:
- Smart Routing evaluates transactions against the ruleset at the site level only if inheritance is removed (
IsInherited = false) and a site level ruleset exists. - When evaluating the transaction at the site level ruleset, Smart Routing checks the rules in the site's ruleset:
- If the transaction doesn't match any rules, it falls back to the default routing logic of approval-based routing.
- If the site has
IsInherited = true, Smart Routing evaluates the transaction against the merchant or merchant group level ruleset.
Smart Routing integrates seamlessly into the payment transaction lifecycle through a comprehensive flow that spans from provider selection to performance feedback.
When a customer initiates a payment, the system collects all the necessary information about the transaction before doing anything else. This includes:
- Who is paying and where: The customer's location and your merchant details (merchant group ID, merchant ID, and site ID)
- How they are paying: The card type, payment network (Visa, Mastercard, etc.), and the amount and currency
- Additional card details: Such as the card category, BIN, issuer country, and funding source
Once all this information is collected, the system quickly checks that everything is valid and recognised before moving to the next step.
The system then decides how to find the best payment provider for this transaction. There are two possible approaches:
- Smart Routing (when enabled): The system uses intelligent decision-making to find the best possible payment provider, considering past performance, business rules, and load balancing.
- Basic Routing (fallback): If Smart Routing isn't available, the system simply picks the first available payment provider on the list.
This is the heart of the process. The system goes through several steps to select the most suitable payment provider:
The system first filters out any payment providers that are currently down, inactive, or incompatible with this specific transaction (for example, a provider that doesn't support a particular card type or country). Only active and capable providers move forward.
Automated downtime detection runs continuously in the background, so providers experiencing an outage or performance degradation are excluded before routing begins. Traffic is redirected to available backup acquirers without manual intervention.
The system checks if there are any pre-configured rules that apply to this transaction. For example, "always use Provider A for transactions from a specific country". Rules are checked one by one until a match is found.
Based on the rules, the system selects the provider using one of the following strategies:
- Best performer: Picks the provider with the highest success/approval rate based on past transaction history.
- Dedicated provider: Some transactions are always routed to a specific provider as per business preference.
- Load balancing: Spreads transactions across multiple providers based on configured weightage to avoid overloading one provider.
Once the best provider is selected, the payment is sent to them for processing. The provider evaluates the transaction and sends back a response.
The outcome is one of three options:
- Authorised: The payment was successful.
- Declined: The payment was rejected by the provider or bank.
- Error: Something went wrong during processing.
If a transaction is declined or fails with a recoverable reason, Smart Routing may automatically retry with an alternative acquirer before the transaction cycle closes. Non-recoverable failures are not retried.
The system records the outcome and closes the transaction cycle once processing is complete or all retry attempts are exhausted.
After every transaction (successful or not), the system records the outcome and feeds it back into its intelligence.
Over time, this continuous learning helps the system make smarter and better routing decisions for future transactions, always improving to ensure the highest possible payment success rates.
Smart Routing continuously monitors the health of all connected acquirers in real time. When an outage or performance degradation is detected, the system automatically redirects the transaction volume to available backup acquirers with no manual intervention required.
- Health monitoring: Smart Routing tracks acquirer availability and performance across your connected providers.
- Outage detection: When a provider goes offline or experiences degraded performance, it's excluded from the routing pool.
- Automatic failover: Incoming transactions are routed to alternative acquirers that remain active and capable of processing the payment.
- Seamless recovery: When the affected provider returns to normal operation, it's reinstated into the routing pool automatically.
- Transactions continue to process during provider outages.
- Customer-facing payment failures caused by acquirer downtime are reduced.
- Operations teams are not required to monitor acquirers or manually switch providers during incidents.
- Revenue loss from unscheduled acquirer downtime is minimised.
When a transaction is declined or fails, Smart Routing evaluates the failure reason and automatically retries with an alternative acquirer — but only where recovery is genuinely possible.
- Initial routing: The transaction is sent to the acquirer selected by your ruleset and routing strategy.
- Failure evaluation: If the transaction is declined or returns an error, Smart Routing assesses whether the failure is recoverable.
- Selective retry: Recoverable failures (e.g., temporary technical issues or provider-specific declines) are retried with an alternative acquirer. Non-recoverable failures (e.g., insufficient funds or closed accounts) aren't retried.
- Retry limit: Failed transactions are retried up to the configured retry count. For example, if the retry count is set to 3, the system attempts up to three retries. Retry attempts stop as soon as a retry is successful or the configured retry count is reached.
- Declined transactions may be recovered without the customer re-entering their payment details.
- Payment friction is reduced, leading to improved checkout completion rates.
- Retry costs are kept in check by only pursuing transactions with genuine approval potential.
- Authorisation rates can improve without a proportional increase in processing costs.
Retry behaviour respects your configured retry count. Each retry attempt is routed to an alternative acquirer based on your ruleset and routing strategy, subject to provider availability and automated downtime detection.
You can use the following parameters to define conditions in your routing rules:
| Parameter | Description | Operators | Value |
|---|---|---|---|
| BIN | The first six to eight digits of the card used for the transaction |
| Free text |
| Card scheme | The card network associated with the payment method. For example, Visa |
|
|
| Exemption type | The type of regulation-based exception applied to the transaction |
|
|
| Funding source | The origin of the funds used for the transaction. For example, Credit |
|
|
| Funding type | The type of payment method associated with the transaction. For example, Card |
|
|
| Issuer name | The name of the card issuer (bank). You'll need to enter the exact issuer name as defined in the system. Abbreviations or partial names may not match. |
| Free text |
| Issuer country | The country of the issuing bank |
| Country code in ISO 3166-1 alpha-2 format and country name (e.g., GB - United Kingdom) |
| Merchant ID | Your unique merchant identifier, as assigned by PXP |
| Free text |
| Shopper country | The customer's country of residence |
| Country code in ISO 3166-1 alpha-2 format (e.g., GB) |
| Site ID | Your unique site identifier, as assigned by PXP |
| Free text |
| Transaction amount | The total amount of the transaction |
| Free text |
| Transaction currency | The currency of the transaction |
| Currency code in ISO 4217 format (e.g., GBP) |
When you create a rule, you can choose between two strategies:
- Approval rate optimized routing: Route transactions based on optimised approval rates at the merchant category code and acquirer level.
- Specific processor: Route transactions to a specific processor of your choice based on performance, region, or business strategy. Note that the options available will depend on your contract.
- Split Volume: Distribute the transaction volume across multiple acquirers by defined percentages (e.g., 40% to Provider A, 30% to Provider B, 30% to Provider C), supporting load balancing, risk diversification, and volume commitment fulfilment.