Routing rules
Complex transaction pathways depend on explicit conditions, priorities and custom parameters. Payment routing rules give operations administrators manual control through Cardflo’s Boolean rules engine, weighted logic and pre-deployment condition testing.
- Category
- Routing
- Capabilities
- 6
- Available on
- All plans
Payment operations administrators require granular control over transaction pathways when static gateway logic proves insufficient. Complex merchant hierarchies, diverse product lines and specific compliance requirements mean that standard flows cannot handle highly bespoke transaction conditions. Teams need an interface to build explicit Boolean pathways that assess multiple custom variables before an authorisation request is dispatched.
Cardflo provides a configuration environment for administrators to deploy exact payment routing rules across multiple acquirer partners. The platform evaluates custom parameters through strict conditional statements, assigning specific priority weights to resolve conflicting logic. Operations teams can construct, arrange and test these manual pathways within a staging environment prior to pushing the new logic into live production.
Our customisable routing rules allow for precise control over transaction flows, prioritising costs and enabling cascading retries across all MIDs. These rules are vital for managing your payments efficiently within our extensive acquirer partner network.
Routing rules overview
The Cardflo orchestration platform includes a dedicated rules engine interface designed for operations personnel who build bespoke processing logic. Rather than relying on algorithmic probability, this environment allows teams to enforce absolute transaction pathways based on precise parameter matches.
Administrators construct complex conditional statements using standard operators to isolate specific variables, custom metadata or bespoke cart values. The system evaluates each payload against these custom payment routing rules in a strict hierarchical order, executing the highest-priority match immediately.
While automated smart payment routing handles probability-based distribution, BIN intelligence provides card verification APIs, and card issuer performance reporting isolates upstream bank metrics, this rules engine exists purely to enforce strict manual logic.
Operations staff retain complete control over pathway definitions, testing Boolean conditions against historical payload data to ensure that custom routing configurations perform exactly as specified before deploying updates to the live orchestration environment.
How routing rules works
Defining custom parameter variables
Administrators begin by mapping custom payload fields within the rules interface to capture bespoke merchant data. The operations team configures the platform to recognise specific string values, integers or custom metadata tags originating from the checkout application. This standardisation ensures that the logic engine can accurately parse unique variables before evaluating any payment routing rules against the inbound transaction.
Building conditional logic statements
Using the interface, operations personnel construct strict conditional pathways based on the defined variables. The team applies standard operators such as equal to, greater than, or contains, linking multiple parameters with AND/OR statements. This creates nested logic trees that explicitly dictate which transactions qualify for specific routes, ensuring that complex processing criteria are translated into executable instructions for the orchestration layer.
Testing and priority weighting
Before deploying the new configuration, administrators assign a numerical priority weight to each rule to dictate the execution order. The logic is then tested against historical payload data within the staging environment. This simulation reveals how the rules engine handles overlapping conditions, allowing the team to verify that the hierarchy correctly resolves conflicts and enforces the intended manual pathway.
Why routing rules matters
Absolute control over transaction flows
Complex merchant environments require processing pathways that reflect specific commercial agreements and operational constraints. By defining precise payment routing rules, operations teams eliminate the uncertainty of algorithmic distribution. This manual oversight guarantees that high-value segments, restricted product categories or specific customer cohorts always follow the exact processing route negotiated with specific acquirer partners, protecting margins and maintaining compliance.
Safe deployment of complex logic
Modifying transaction pathways carries the risk of unintended misrouting if logic conflicts occur. The ability to structure nested Boolean conditions and test priority weighting prevents administrative errors from affecting live traffic. Operations personnel can validate their manual routing configurations in a sandbox environment, ensuring that highly specific processing criteria execute perfectly before exposing the rules to actual customer funds.
Regulatory notes for routing rules
Scheme rules regarding dedicated merchant processing
The major card network schemes enforce strict regulations detailing how transaction volume must be segregated across different commercial entities.
Merchants operating multiple distinct sub-brands must ensure that specific traffic is processed through the correct merchant identification numbers to maintain absolute compliance with scheme data integrity standards.
Administrators use the rules engine interface to mandate continuous compliance across complex merchant portfolios. By configuring precise Boolean logic based on custom brand variables, operations teams guarantee that distinct transaction types are completely isolated.
This manual oversight prevents unauthorised aggregation and protects the organisation from scheme-imposed financial penalties.
Regional data processing obligations
Payment operations teams must often configure strict transaction pathways to satisfy regional data residency requirements or specific local legislation. Certain jurisdictions mandate that transactions involving resident consumers or specific regulated services are processed exclusively by acquirer partners situated within that specific geographic or economic territory.
Constructing explicit payment routing rules allows compliance personnel to enforce these territorial restrictions at the gateway level. Administrators can write absolute logic statements that intercept specified metadata or custom tags, ensuring that restricted payloads never travel to acquirer endpoints located outside the approved regulatory jurisdiction.
Routing rules use cases
Threshold and currency branching
Payment operations administrators define Boolean conditions combining transaction amount, presentment currency and merchant-defined order attributes, but overlapping thresholds can send a payment down the wrong pathway. Cardflo provides a rules engine for nested IF/THEN logic, explicit rule priority and controlled testing against representative transaction inputs before publication.
MID selection by sales channel
Retail groups processing website, app and in-store transactions may need each channel and legal entity mapped to the correct MID for settlement and reconciliation. Cardflo lets administrators combine channel, entity and payment method parameters, weight competing rules by priority and validate the resulting acquirer partner pathway before activation.
Restricted product category routing
Merchants selling regulated and unrestricted inventory in one checkout must identify orders containing age-restricted or licence-dependent product categories before routing them to an eligible MID. Cardflo supports custom product metadata, nested AND/OR conditions and test cases that confirm restricted baskets reach the intended acquirer partner configuration.
Wallet token pathway rules
Payment teams accepting Apple Pay, Google Pay and network-tokenised cards may require different gateway endpoints according to wallet type, token assurance data or device channel. Cardflo enables administrators to define method-specific parameters, order mutually exclusive rules and test wallet payload conditions without altering the merchant’s wider card acceptance logic.
Routing rules by the numbers
This range reflects typical improvements seen by merchants. These occur when moving from a single-acquirer setup to a multi-routed environment that prioritises local processing.
These are typical savings achieved by minimising inter-regional scheme fees and optimising for lower-cost acquirers via intelligent routing logic.
This is industry-standard availability for businesses with multi-gateway failover strategies. These strategies prevent downtime during individual processor outages.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Routing rules
- Construct complex conditional pathways using standard Boolean operators applied to custom transaction payload variables.
- Assign explicit priority weighting to resolve conflicts when a single transaction triggers multiple distinct conditions.
- Evaluate new logic configurations against historical authorisation data within an isolated staging environment before deployment.
- Group multiple statement evaluations into nested conditions to handle highly specific, multi-layered merchant processing requirements.
- Define bespoke parameters within the rules engine interface to capture unique shopping cart or customer attributes.
- Configure manual routing logic that directs matching payloads to precise merchant identification numbers across the network.
A short scoping call, then a written plan for your MIDs.
Questions about Routing rules
How does the system resolve conflicts between multiple routing rules?
The payment routing rules engine employs a strict priority weighting system to handle overlapping conditions. Administrators assign a numerical value to every logic statement during configuration.
When an inbound transaction matches multiple parameters simultaneously, the platform evaluates the hierarchy and executes the pathway associated with the highest priority weight.
Operations teams can review these weightings within the dashboard and adjust the execution order to ensure that broader catch-all policies do not override highly specific instructions designed for edge cases.
Can operations teams test conditional logic before pushing to production?
Yes, the platform includes a dedicated staging environment for validating manual payment routing setup. Administrators can upload historical payload data or generate synthetic transaction variables to simulate live processing.
The logic engine processes these test payloads against the newly configured Boolean statements and outputs a detailed execution log.
This allows payment operations personnel to verify that their custom pathways trigger correctly and that priority weightings resolve as intended before committing the configuration to the live environment.
What syntax is required to build nested conditions?
The interface uses standard Boolean operators to link multiple variables into cohesive logic blocks. Administrators can select AND, OR, and NOT operators from the configuration dashboard, applying them to defined parameters such as exact string matches, numerical ranges or custom metadata inclusions.
Operations personnel can group these statements into nested structures, requiring a transaction to satisfy a complex set of prerequisite conditions before it qualifies for the specific manual route defined in the payment routing rules.
Are custom payload variables supported within the logic engine?
The platform fully supports custom parameter definitions, allowing merchants to route based on proprietary data sent within the transaction payload. Administrators map these unique fields upon initial setup, defining whether the engine should expect a string, a boolean value or an integer.
Once mapped, these custom tags become available as standard variables within the rules builder, enabling operations teams to construct custom pathways around bespoke shopping cart attributes, internal customer tiers or specific promotional identifiers.
Related features.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.