Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Revenue
Platforms and marketplaces
Money management
Developer resources
Overview
About Stripe payments
Upgrade your integration
Payments analytics
Online payments
OverviewFind your use caseUse Managed Payments
Use Payment Links
Use a prebuilt checkout page
Build a custom integration with Elements
Build an in-app integration
Payment methods
Add payment methods
Manage payment methods
Faster checkout with Link
Payment interfaces
Payment Links
Checkout
Web Elements
In-app Payments
Payment scenarios
Handle multiple currencies
Custom payment flows
Flexible acquiring
Orchestration
    Overview
    Route payments to multiple processors
    Manage rules
    Cross-processor retries
In-person payments
Terminal
Beyond payments
Incorporate your company
Crypto
Agentic commerce
Financial Connections
Climate
Understand fraud
Radar fraud protection
Manage disputes
Verify identities
HomePaymentsOrchestration

Cross-processor retries with OrchestrationPrivate preview

Want access to Orchestration?

Orchestration is in private preview. Share your email address to request access.

Payments can fail for various reasons such as network issues, processor outages, or temporary declines (for example, insufficient funds). Many of these failures are recoverable. With Orchestration, you can automatically retry failed payments using a different processor than the one that submitted the original attempt, helping you to recover more revenue.

Set up payment retries in the Dashboard

To configure payment retries:

  1. Navigate to Payments > Orchestration > Rules.
  2. Create new rules or open existing rules. If you’re making changes to existing rules, you must duplicate it and then edit the draft of your duplicated rules.
  3. In the rule builder, add an Action to configure retry behavior:
    • Main processor: The processor to use for the initial payment attempt.
    • Retry processor: The processor to use if the initial attempt fails.

This setup enables seamless retries of failed payments, improving the likelihood of successful processing.

Cross-processor retry behavior

When a payment fails on the main processor, the retry logic depends on several factors.

  • 3D Secure: If 3D Secure (3DS) authentication is attempted on the first attempt on your main processor and your customer doesn’t authenticate successfully, or authenticates successfully but the payment attempt still fails, Orchestration doesn’t retry the transaction on the retry processor. We send a payment_failed webhook event instead.
  • Ineligible features: If a payment uses a feature that isn’t supported by the retry processor, such as Stripe Connect’s on_behalf_of parameter, Orchestration won’t retry with that processor after the first failure.
  • Blocked transactions: If Stripe is your main processor and blocks a transaction (for example, a high-risk payment identified by Radar) Orchestration treats this as a decline and retries the payment on your chosen retry processor.
  • Adaptive Acceptance: If you have Adaptive Acceptance enabled and Stripe is your main processor, then Stripe might initiate an additional retry on a declined transaction, before triggering a cross-processor retry. If Stripe is your retry processor, then Stripe might ultimately initiate two retries, one as a cross-processor retry and the other under Adaptive Acceptance.
Was this page helpful?
YesNo
  • Need help? Contact Support.
  • Join our early access program.
  • Check out our changelog.
  • Questions? Contact Sales.
  • LLM? Read llms.txt.
  • Powered by Markdoc