Smart Routing
Our fragment-based payment routing, gives you flexibility to design custom routing logic that perfectly matches your business needs.
Whether you want to route by transaction volume, card issuer, or specific currencies - Fragments allow you to build it your way.
🔍 What is Smart Routing?
Smart Routing gives you full control over how your transactions are directed to payment processors. With the right routing strategy, you can:
- Maximize transaction approval rates
- Optimize processing costs
- Stay resilient with processor failover strategies
With our Fragment system, you can mix and match routing logic to build highly customised flows.
Each retail channel has its own Smart Routing Rule Set.
The currently selected Retail Channel will be visible when the drop-down is not expanded.
Your Smart Routing rules and fragments can be given a custom name. Naming your rules and fragments is highly recommended, especially as your routing configurations grow more complex.
📜 Rules & Rule Sets
A rule consists of one, or more input fragments, and a single output fragment. A Rule determines which Payment Processor the BR-DGE routing engine will send a transaction to.
A rule set is the collective name for all the individual rules on a single retail channel. When viewing the "Smart Routing" tab of the BR-DGE portal you can see one, or more, rules. Collectively, these are known as a "Rule Set".
🧩 What Are Fragments?
Fragments are the building blocks of BR-DGE routing logic.
Using one or many Input fragments you can define where a transaction is routed to, based on input criteria matching your specified requirements. This is controlled by using your input fragment to determine when a rule should be used, and an output fragment to route the transaction to the selected Payment Processor.
🔣 Input Fragments
These are the conditions BR-DGE will match on, otherwise know as the “when” parts of your rule.
Input Fragments let you specify which kind of transactions a rule applies to. You can use one fragment, or combine several together to build your input conditions.
The currently available Input Fragments are:
| Fragment Type | Description |
|---|---|
| Monetary | Define ranges of transaction amounts and match on currency |
| BIN Metadata | Match on Issuer, Network, Country of issuing bank or currency from the Card |
| Payment Instrument | Select one or more Payment methods such as Apple Pay, Google Pay, Card |
| Merchant Metadata | Route with key/value pairs you specify in your payment request |
| Payment Rail | Route Transactions based on the rails a payment is using |
| BIN | Route transactions using specific BINs or BIN Ranges |
🎯 Output Fragment
This is the destination for your transaction, otherwise known as the “then” part of your rule
Output Fragments are where your transaction will be sent once it matches all the input conditions. The output fragment determines which Payment Processor the transaction will be sent to.
The currently available Output Fragments are:
| Fragment Type | Description |
|---|---|
| Volume Split Routing | Distribute matched transactions across processors by percentage |
| Processor Priority List | Define fallback processors in order of preference |
The following example rule shows how you can combine multiple input fragments to match on, and then route them to an output fragment.
An example rule with multiple input fragments, and a "Volume Split" output fragment
🕵 How does Smart Routing Work?
BR-DGE Smart Routing use a combination of different fragment types to build a "Rule"; a custom way to route your transactions. Each rule must contain at least one input fragment, and a single output fragment.
If you do not specify any input fragments when creating your rule, BR-DGE will automatically input an "All" fragment. Which will match on 100% of your transactions.
When processing a transaction the BR-DGE routing engine will check your Rule Set from top to bottom; selecting the first suitable rule that it finds. This "top-down" approach ensures consistent transaction processing, and prevents conflicting rules from interfering with each other.
If a transaction does not match any Rules in your Rule Set it will be declined, and will not be routed to any Payment Processor. To avoid this scenario, and protect your transactions from any misconfiguration of Rules, we highly recommend the final Rule in your Rule Set contains an "All" input fragment to act as a safety net.
You can generate an "All" Input Fragment by creating a rule with no specified input fragments. When creating your rule leave the "Rule Inputs" section blank to allow BR-DGE to auto-populate an "All" Input Fragment.
🔀 Initial Transaction Attempt
When you initiate a transaction, the BR-DGE routing engine checks the details of the transaction against the Rules in your Rule Set. In the event that a transaction could match multiple Rules in the Rule Set, the first matched rule in the list will be used to route the transaction.
Once a rule has been selected, the routing engine will stop evaluating other Rules in the Rule Set, and proceed with the transaction.
🔄 Transaction Failover Events
If your transaction enters a state where it can be retried with another processor the BR-DGE routing engine will automatically attempt to retry the payment with the next suitable Payment Processor in the output fragment from the Initial Transaction step above.
If the output fragment from the above step does not contain any additional Payment Processors, the BR-DGE routing engine will recheck to your Rule Set to determine if there are any other suitable Rules that can be used to re-route your transaction. If there are no other suitable rules for your transaction, the transaction will declined with the latest available response code.
Updated 7 days ago