Routing Group Rules API
The Routing Group Rules API allows you to create and manage payment routing rules that control how transactions are processed across different payment providers and acquirers. This enables sophisticated payment orchestration strategies.
Overviewโ
Routing Group Rules provide:
- Payment Orchestration - Route transactions to different providers based on rules
- Load Balancing - Distribute transaction volume across multiple acquirers
- Failover Support - Automatically route to backup providers when primary fails
- Cost Optimization - Route based on transaction costs and fees
- Geographic Routing - Direct payments based on customer or card location
- Card Type Routing - Route specific card types to optimal providers
How Routing Rules Workโ
- Define Rules - Create routing rules with conditions and target providers
- Set Priority - Assign priorities to determine rule evaluation order
- Apply Conditions - Specify when rules should match (amount, currency, card type, etc.)
- Configure Actions - Define where matching transactions should be routed
- Monitor Performance - Track routing decisions and optimize rules
Rule Conditionsโ
Rules can match on various transaction attributes:
Amount Conditionsโ
- Minimum and maximum transaction amounts
- Currency-specific thresholds
Card Conditionsโ
- Card brand (Visa, Mastercard, etc.)
- Card type (credit, debit, prepaid)
- Issuing country
- BIN ranges
Currency Conditionsโ
- Transaction currency
- Settlement currency
Metadata Conditionsโ
- Custom metadata fields
- Merchant category codes
Use Casesโ
Multi-Acquirer Setupโ
Route transactions to different acquirers based on card type or amount to optimize acceptance rates and costs.
Geographic Optimizationโ
Route domestic transactions to local acquirers for better rates and international transactions to global providers.
Failover Configurationโ
Set up backup routing rules that activate when primary providers experience issues.
Cost Optimizationโ
Route low-value transactions to providers with lower per-transaction fees and high-value transactions to those with lower percentage fees.
Risk Managementโ
Route high-risk transaction patterns to providers with enhanced fraud detection.
Available Endpointsโ
- Create Routing Rule - POST /routing_group_rules
Rule Structureโ
Each routing rule contains:
Identificationโ
- id - Unique rule identifier
- name - Human-readable rule name
- description - Detailed rule description
Conditionsโ
- conditions - Array of condition objects
- match_type - How conditions combine (all/any)
Actionsโ
- provider - Target payment provider
- priority - Rule evaluation order
- weight - Load balancing weight (optional)
Statusโ
- enabled - Whether rule is active
- created_at - Creation timestamp
- updated_at - Last modification timestamp
Best Practicesโ
Do Thisโ
- Start simple - Begin with basic rules and add complexity gradually
- Test thoroughly - Validate rules in test mode before production
- Monitor metrics - Track routing decisions and success rates
- Document rules - Keep clear documentation of routing logic
- Use priorities wisely - Leave gaps in priority numbers for future rules
- Set up failovers - Always have backup routing rules
Don't Do Thisโ
- Don't over-complicate - Complex rule sets are hard to debug
- Don't forget testing - Always test in sandbox first
- Don't ignore metrics - Monitor to catch issues early
- Don't create conflicts - Ensure rules don't have overlapping conditions
- Don't skip failovers - Have backup routes for all critical paths
Performance Considerationsโ
Rule Evaluationโ
- Rules are evaluated in priority order
- First matching rule is applied
- Keep high-traffic rules at higher priority
Cachingโ
- Rule configurations are cached for performance
- Changes may take a few seconds to propagate
Monitoringโ
- Track routing decisions via webhooks
- Monitor provider health and adjust rules accordingly
Related Resourcesโ
Need help? Contact support@omise.co