Rule-Based Routing
Rule-based routing gives you deterministic control over where payments are routed. You define rules using a straightforward decision model: conditions are checked against the transaction (IF), and a routing outcome is applied (THEN). Pulse supports two strategies within this model:
- Priority routing evaluates rules in order and selects the single highest-priority payment partner that matches.
- Volume-based routing distributes eligible traffic across multiple payment partners using count-based or amount-based splits.
Both strategies share the same set of rule selectors, so you can target transactions by payment mode, amount range, currency, card network, issuer, UPI flow, and other attributes. Rules can also target a specific Payment Partner Account when a merchant holds multiple credentials for the same partner.
When a payment request arrives, Pulse evaluates the active rule set. Each rule contains a condition set (the selectors that must match the transaction) and a routing outcome (which payment partner to use). The strategy determines how the winning route is chosen: priority routing picks the first match in order, while volume-based routing distributes traffic according to configured splits. Once a route is selected, Orbit executes the payment through the chosen payment partner path.
Rule Selectors
Pulse uses a consistent set of rule selectors across both priority and volume routing. Selectors define the conditions a transaction must meet for a rule to apply. Multiple selectors can be combined within a single rule -- all conditions must match (AND logic) for the rule to apply.
Rule Selectors Reference
General selectors apply across all payment modes:
| Selector | Meaning | Example Values | Priority | Volume | Notes |
|---|---|---|---|---|---|
| Payment mode | Match transactions by payment mode | Credit Card, Debit Card, UPI, Netbanking, Wallet, Card EMI, Cardless EMI | Yes | Yes | — |
| Amount range (min) | Minimum transaction amount | 100, 500, 1000 | Yes | Yes | — |
| Amount range (max) | Maximum transaction amount | 5000, 10000, 50000 | Yes | Yes | — |
| Currency | Restrict to specific currencies | INR, USD, GBP | Yes | Yes | — |
Card selectors apply to credit cards, debit cards, and prepaid cards:
| Selector | Meaning | Example Values | Priority | Volume | Notes |
|---|---|---|---|---|---|
| Card network | Card scheme or network | Visa, Mastercard, RuPay, Maestro, Amex, Diners, JCB, Discover | Yes | Yes | — |
| Card type | Corporate or retail cards | Corporate, Retail | Yes | Yes | — |
| Card geography | Domestic or international cards | Domestic, International | Yes | Yes | — |
| Issuer bank | Bank that issued the card | HDFC, SBI, ICICI, Axis, and others | Yes | Yes | — |
| BIN range | Bank Identification Number prefix (6--8 digits) | 512345, 411111 | Yes | Yes | Include or exclude specific BIN ranges |
Payment mode-specific selectors:
| Selector | Meaning | Example Values | Priority | Volume | Notes |
|---|---|---|---|---|---|
| UPI flow | Type of UPI payment experience | Intent, QR, Collect | Yes | Yes | UPI only |
| Netbanking bank | Bank for netbanking transactions | HDFC, SBI, ICICI, and others | Yes | Yes | Netbanking only |
| Wallet provider | Digital wallet provider | Paytm, PhonePe, Amazon Pay, and others | Yes | Yes | Wallets only |
| Card EMI tenure | EMI tenure duration in months | 3, 6, 9, 12, 18, 24 | Yes | Yes | Card EMI only |
| Cardless EMI issuer | Cardless EMI provider | ZestMoney, HDFC Bank, ICICI Bank, and others | Yes | Yes | Cardless EMI only |
Coming soon:
| Selector | Meaning | Example Values | Priority | Volume | Notes |
|---|---|---|---|---|---|
| SKU and custom attributes | Product SKUs and custom order fields | SKU IDs, custom key-value pairs | Yes | Yes | Coming soon |
| Campaign window | Date and time-based routing windows | Date ranges, day-of-week, time windows | Yes | Yes | Coming soon |
Product configuration for routing rules is coming soon in Command Center. Currently, routing rules are configured by the Nimbbl team on your behalf.
For context on the payment modes and partners you can target, see the Orbit payment modes and Orbit payment partners pages.
Priority Routing
Priority routing is best when you want predictable, ordered outcomes that reflect commercial or operational preferences.
How Priority Routing Works
Rules are evaluated top-to-bottom. The first rule whose conditions match the transaction determines the route. Only one payment partner is selected per transaction. If no rules match, Pulse falls back according to the configured fallback behavior. This makes routing outcomes fully predictable -- the rule order you define is the order Pulse follows.
Use Cases
Common scenarios for priority routing include:
- Cost optimization -- route to the payment partner with the lowest processing rates for a given payment mode or transaction segment, reducing your overall payment costs.
- Corporate cards to a preferred partner -- route corporate card transactions to a payment partner with better commercial terms for that segment.
- Splitting UPI flows -- send UPI Intent transactions to one payment partner while directing UPI QR to another, based on each partner's strengths.
- High-value card payments -- direct card payments above a certain amount to a specific partner with better authorization rates for that transaction range.
Configuration
When configuring priority routing, you define:
- Rule order -- the sequence in which rules are evaluated (evaluation priority).
- Conditions -- the rule selectors that must match the transaction (payment mode, amount range, card network, etc.).
- Target payment partner -- the payment partner to route to when conditions match.
- Credential label (optional) -- if the merchant has multiple accounts with the selected partner, a
cred_labelcan specify which account to use.
Volume Routing
Volume-based routing is best when you want to spread traffic across multiple payment partners, whether to meet commercial commitments, reduce single-partner dependence, or benchmark performance.
How Volume Routing Works
Once a transaction matches a volume rule's conditions, Pulse selects a payment partner according to the configured split. Splits can be defined by count (percentage of payment attempts) or by amount (percentage of total routed value). For example, a 60/40 count-based split routes 60% of eligible attempts to Partner A and 40% to Partner B. The split is maintained over time so that actual traffic distribution converges on the configured ratios.
Use Cases
Common scenarios for volume-based routing include:
- Meeting commercial commitments -- distribute traffic across payment partners in proportions that align with contractual volume obligations.
- Reducing single-partner dependence -- spread transactions to avoid concentration risk on any one partner.
- Benchmarking partner performance -- use A/B splits to compare authorization rates, latency, or cost across partners under real traffic conditions.
Configuration
When configuring volume-based routing, you define:
- Rule conditions -- the same rule selectors available in priority routing (payment mode, amount range, card network, etc.).
- Split ratios -- the percentage each payment partner should receive.
- Split type -- whether the split is measured by count (percentage of attempts) or by amount (percentage of routed value).
- Credential label (optional) --
cred_labelis supported per split leg, allowing you to target a specific Payment Partner Account within each partner's share.
Route to Specific Payment Partner Accounts
When a merchant holds multiple credentials (for example, separate MIDs) for the same payment partner, routing rules can target a specific account using the cred_label field. This applies to both priority and volume-based routing.
Use cred_label when you have multiple MIDs or accounts for the same payment partner and want a rule to target a specific account. The selected label is available in transaction metadata for reconciliation.
The credential label is part of the routing outcome, not a rule selector. It tells Pulse which specific account to use after the payment partner has been selected. This is useful when different business segments, brands, or product lines need to route through distinct credential sets under the same partner.