keepcalculator

06 Numbers and Powers

Payment Routing: How Orchestration Platforms Work

Card No. 06·51936 · Updated · Standard formula, shown below

Payment orchestration platforms sit between your checkout and multiple payment providers, automatically choosing which provider processes each transaction. You configure rules and priorities, and the platform routes each payment based on factors like cost, success rate, and geographic location. This guide explains the routing logic step by step.

What You’ll Need

  • An account with a payment orchestration platform (e.g., Spreedly, Finix, or similar)
  • At least two payment providers (gateways or acquirers) connected to the platform
  • Access to the platform’s dashboard or API documentation
  • Basic understanding of your transaction volumes and target markets

Step-by-Step

  1. Connect your payment providers. In the platform’s dashboard, add each provider (e.g., Stripe, Adyen, PayPal) by entering your API credentials. The platform will verify the connection and show the provider’s status as active.
  2. Set up routing rules. Navigate to the routing or smart routing section. Create rules based on criteria like transaction amount, currency, card type, or customer location. For example, route transactions under $50 to Provider A and larger ones to Provider B.
  3. Define provider priority. For each rule, assign a primary and fallback provider. The platform tries the primary first; if it fails, it automatically tries the fallback. You can also set load balancing percentages (e.g., 70% to Provider A, 30% to Provider B).
  4. Enable fallback logic. Turn on automatic retry or failover. The platform will detect a failed transaction (e.g., timeout, declined, or provider down) and immediately route to the next provider in the list.
  5. Add dynamic factors (optional). Use advanced settings to factor in real-time data like provider success rates, processing fees, or estimated response times. The platform calculates a score for each provider and picks the best one per transaction.
  6. Test the routing. Use the platform’s sandbox mode to simulate transactions. Verify that the correct provider is chosen based on your rules, and that fallback works when you simulate a failure.
  7. Deploy and monitor. Switch to live mode and monitor the dashboard for routing decisions. Check logs to see which provider handled each transaction and whether any fallback was triggered.
  8. Adjust rules based on performance. Review success rates and costs monthly. Update your rules to favor providers with higher approval rates or lower fees, and re-test after changes.

Common Mistakes

  • Ignoring provider-specific limitations. Some providers don’t support certain card types or countries. Your rules must account for these to avoid unnecessary failures.
  • Setting too many rules. Overly complex rules can cause confusion and unexpected routing. Start with a few key criteria and expand gradually.
  • Not testing fallback. If you don’t simulate a provider outage, you won’t know if the fallback works until it’s too late.
  • Forgetting to update rules. Provider fees and success rates change. Review your routing logic regularly to keep it optimal.

Tips

  • Start with simple rules. Begin with currency or amount-based routing, then add complexity as you learn.
  • Use load balancing for high-volume periods. Distribute traffic to avoid overloading a single provider.
  • Monitor provider health. Set up alerts for when a provider’s error rate spikes, so you can adjust routing proactively.
  • Keep a backup provider. Always have at least one provider that can handle all your transaction types as a safety net.

Troubleshooting

  • Transactions are not routing as expected. Check that your rules are in the correct order (the platform evaluates them sequentially). Also verify that the transaction meets the rule’s criteria (e.g., currency matches exactly).
  • Fallback is not triggering. Ensure that the fallback provider is active and configured for the same payment method. Also check if the platform requires a specific error code to trigger fallback.
  • Provider is rejecting all transactions. Test the provider directly with a small transaction to confirm it’s not a routing issue. If the provider is down, the platform should have automatically switched to the fallback—if not, contact support.
  • High decline rates after a change. Review the new rules for any mistake like a typo in the currency code or an incorrect priority. Temporarily revert to the previous configuration and re-test.

Frequently Asked Questions

What is payment orchestration?

It’s a layer that connects your business to multiple payment providers and manages the routing, retries, and reconciliation of transactions.

Can I route based on the customer’s country?

Yes, most platforms allow geo-routing. You can send transactions from Europe to a provider with better EU acquiring rates.

How does the platform know which provider to use?

It uses your rules and, optionally, real-time analytics like success rate or cost to score each provider and pick the best one.

What happens if all providers fail?

The transaction is declined, and the customer sees an error. You can set up a retry mechanism for transient failures, but if all providers decline, the payment cannot be processed.

Is there a cost to routing?

Some platforms charge per transaction or a monthly fee. Provider fees still apply. Routing itself doesn’t add cost, but the platform’s pricing may.

Can I change routing rules without downtime?

Yes, most platforms apply changes instantly. You can update rules and test them in sandbox before going live.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →