Private preview
Route payments to multiple processors Private preview
Use Stripe Orchestration to route payments across your payment processors.
Want access to Orchestration?
Stripe Orchestration is in private preview. Share your email address to request access.
Stripe Orchestration lets you configure payment processor selection using rules you create in the Dashboard. You can route payments based on conditions such as card country, currency, amount, and so on. Within your rules, you can set up retry actions to attempt a payment that failed on your main processor one more time on another chosen processor. You can also view analytics for payment success rates and accepted payment volume across processors.
Before you begin
To access Orchestration, contact your Stripe representative who can guide you through the following steps:
- Confirm that Stripe supports the destination processor.
- Onboard your Stripe account with Orchestration. You need to provide API keys for your destination processor in the Stripe Dashboard.
- Confirm your Stripe integration supports Orchestration. Your Stripe representative can assist as you go live.
Link transactions
Link payment credentials can’t be transferred between payment processors. Link transactions are automatically excluded from your routing rules and always processed on Stripe, regardless of your routing configuration.
Add test rules in a sandbox Dashboard
Rules contain the conditions and actions for routing payments to a specific processor.
- Create a sandbox if you don’t have an existing one. You use the sandbox to add and test rules before going live.
- Open the sandbox from the Dashboard account picker.
- On the Orchestration page in the Dashboard, select Add test rules .
- Add rules with a condition that routes the payment to one of the available processors if the Card country is equal to United Kingdom . Add an action to route the payment to Stripe if the condition isn’t met.
- (Optional) Add a processor to retry the payment one more time if the payment fails on the main processor.
- Click Activate test rules .
Create a PaymentIntent Server-side
You can also configure payments created by Billing, Checkout Sessions, Payment Links, or in the Dashboard to follow your rules. These payments automatically create a PaymentIntent. Contact your Stripe representative to configure these automatically-created PaymentIntents to use Orchestration.
Use the API key from your selected sandbox for the PaymentIntent examples. When you create a PaymentIntent, include the payments_orchestration parameter to enable Orchestration.
Command Line
Select a language
cURL
Stripe CLI
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
Orchestration doesn’t support the Setup Intents API and flexible acquiring features on other processors. For transactions that involve a 3D Secure request, you’re responsible for providing Stripe with the Acquirer BIN that corresponds to the processor you route those transactions to. Check with your Stripe representative if you’re unsure whether Orchestration supports the features you use.
Verify your test rules Server-side Dashboard
Use test cards to make sure Stripe routes payments to the processors specified by your rules. For example, to test if payments route to the processor you selected when the card country equals the United Kingdom, you can use the test payment method pm_card_gb:
Command Line
Select a language
cURL
Stripe CLI
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
After creating a test payment, view the details page for your payment to see which processor the payment routed to. On the payment details page, you can see the processor under Processor. Recent activity also shows the processor and the rules that routed the payment. Click the link to view the rules that routed this payment.
The Payment Record contains the execution history for payments where Orchestration is enabled. Retrieve the Payment Record using its ID from the PaymentIntent.
Command Line
Select a language
cURL
Stripe CLI
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
Alternatively, enter the Payment Record ID in the Inspector in Workbench.
Verify which processor the payment routed to by viewing the processor_details hash:
Payment Record object
{
"id": "pr_123456",
"object": "payment_record",
"amount_authorized": {
"currency": "gbp",
"value": 12345
},
...
"processor_details": {
"type": "processor_a",
...
},
...
}
Optional Update your reporting back end Server-side
Optional Update your webhook handler Server-side
Add rules for your live integration Dashboard
After testing your integration, exit your sandbox and add rules for your live integration. Orchestration is enabled as soon as you activate your rules. Learn about other conditions and actions to route payments.
Monitor processor performance
After enabling Orchestration for your live payments, use the Dashboard to monitor performance for your processors.
- On the Orchestration overview page , access performance analytics and payment success rates across your processors. You can filter this data to see performance by currency, card brand, card country, card type, or transaction type.
- On the Payment details page , view processor information for an individual payment.
- On the Payments analytics page , analyze your overall payment success rate to find out where payments fail. Use the processor filter to view only the payments routed through a specific processor.
The Dashboard doesn’t currently display balance summary and activity reports, dispute status, or receipts for payments processed on other processors. Data can take up to 2 days to populate. The Orchestration data that we share in the Dashboard relies on data provided by you and your other processors.
Error prevention
If you enable error prevention during onboarding, Stripe makes sure that payments don’t fail only because of features that aren’t supported by other payment processors through Orchestration. Specifically, when the routing logic directs a payment to a processor (whether it’s the main processor or a retry processor), and a required feature for the payment isn’t supported, we automatically attempt to process the payment on Stripe instead of returning an error. If we’re the main processor and the payment fails on Stripe, we evaluate whether the retry processor can handle the payment and, if not, we don’t attempt to route the payment to the retry processor.
This fallback behavior helps maximize successful payments by preventing failures caused by processor feature limitations.