Payment Orchestration

What the routing layer decides

Payment orchestration sits above more than one processing connection and makes a per-transaction choice: which provider receives this attempt, and what happens if it fails. In Stripe’s Orchestration, which is in private preview, that choice is written as dashboard rules whose conditions test card country, currency and amount, with an optional action that retries a failed payment once on another chosen processor.

Source: Stripe, “Orchestration” (Stripe’s private-preview multiprocessor routing product); Stripe, “Route payments to multiple processors” (Stripe rule conditions, cross-processor retry and destination onboarding), accessed 2026-09-04.

Keep the routing layer distinct from the components it selects between: a payment gateway, a payment processor and a merchant acquirer each have their own entry in this glossary. Orchestration chooses among those connections rather than replacing any of them — in Stripe’s product a third-party processor continues to act as the processor for payments routed to it.

Source: Stripe, “Orchestration” (Stripe’s private-preview multiprocessor routing product), accessed 2026-09-04.

Routing does not move the contract

Stripe adds that all related activity, including processing fees and liability for transaction losses, stays subject to the terms you agreed with that processor, and that its Orchestration does not support disputes or settlement-related activity — those go to the third-party processor’s own dashboard. Onboarding a destination is its own project: under Visa’s rules, before contracting with a prospective merchant an acquirer or payment facilitator must conduct an adequate due diligence review, including a site visit to the business premises (if applicable) or suitable alternative.

Source: Stripe, “Orchestration” (Stripe’s private-preview multiprocessor routing product); Visa, “Visa Core Rules and Visa Product and Service Rules” (§5.2.1.2 “Due Diligence Review of Prospective Merchant or Sponsored Merchant”; the section carries no regional limiter, unlike the neighbouring US Region rules §5.2.1.4 and §5.2.1.5; edition 18 April 2026), accessed 2026-09-04.

So chargebacks, refunds and funding records stay attached to whichever provider ran the payment. In Stripe’s setup each destination is a processor you supply API keys for in the Stripe Dashboard, so the merchant identification number and merchant account behind it still matter to reconciliation. How a routing layer relates to your acquiring relationships differs by provider.

Source: Stripe, “Orchestration” (Stripe’s private-preview multiprocessor routing product); Stripe, “Route payments to multiple processors” (Stripe rule conditions, cross-processor retry and destination onboarding), accessed 2026-09-04.

Retry rules run inside scheme limits

A retry is not a free choice. Visa’s rules set what a merchant may do after each class of decline, and they also govern routing reference data: an acquirer that chooses to use the Account Range table Visa provides to determine authorization routing must install and use it within 6 business days of receipt.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (§7.3.1.1 “Account Range Table for Authorization Routing”; the section carries no regional limiter, unlike §7.3.1.2, which applies in the AP Region only; edition 18 April 2026), accessed 2026-09-04.

Table 7-2 sets the reattempt limit per decline category, unless §7.3.6.2 specifies otherwise for Mobility and Transport Transactions. The examples below exclude codes 70 and 1A, which the table limits to the CEMEA and Europe Regions.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (§7.3.6.3 “Use of Authorization Response Codes” and Table 7-2 “Decline Response Code Use”; the section carries no regional limiter, and regional codes are excluded above; edition 18 April 2026), accessed 2026-09-04.

Failover carries a second constraint. §1.7.2.1 says a party that reattempts an authorization request following a decline response must not intentionally manipulate any data elements from the original request, and it names the acquiring identifier, acquirer and merchant country, MCC, point-of-sale entry mode and the electronic commerce indicator among them; merchant outlet country data must stay the same throughout the transaction life cycle. The rule addresses manipulation of the original request’s data, not which acquirers you contract with, so how a cross-processor failover is treated is a question to settle with each acquirer before relying on it.

Source: Visa, “Visa Core Rules and Visa Product and Service Rules” (§1.7.2.1 “Complete and Valid Transaction Data”; a Visa Core Rule with no regional limiter; edition 18 April 2026), accessed 2026-09-04.

Feature parity is where multi-processor routing breaks

Stripe warns that a feature which normally works on Stripe may fail on the destination, returning a 400 error code of orchestration_unsupported. Its documented gaps include multicapture, 3-D Secure with Apple Pay and Google Pay (DPAN), and Google Pay (FPAN) on Adyen; an optional error-protection setting routes such payments back to Stripe instead. Those are one provider’s limits across its three supported destinations, not a general property of orchestration.

Source: Stripe, “Supported Orchestration features” (feature gaps across Stripe’s three supported destination processors), accessed 2026-09-04.

• Capture behaviour: automatic and manual, and whether more than one capture is supported.
• Whether 3-D Secure runs on the destination, and on which wallet paths it does not.
• Refunds: full and partial support, and which provider administers them.
• Wallet and network-token support, destination by destination.
• Recurring and stored-credential handling.
• Statement descriptor fields, which differ between processors.

Source: Stripe, “Supported Orchestration features” (feature gaps across Stripe’s three supported destination processors); Stripe, “Orchestration” (Stripe’s private-preview multiprocessor routing product), accessed 2026-09-04.

Stored credentials do not travel for free

Moving a saved card between processors is its own problem. Stripe’s Vault and Forward API tokenizes card details in its vault and routes that data to third-party endpoints, and the same page records the edges. Credentials saved through Link cannot be transferred between processors and are excluded from forwarding. Card security codes expire after a period and on use with the API. The forwarding API does not confirm or capture PaymentIntents, so it is possible to capture on Stripe a payment already captured elsewhere.

Source: Stripe, “Forward card details to third-party API endpoints” (Stripe vault portability limits and duplicate-capture warning), accessed 2026-09-04.

Measure it honestly

Approval-rate comparisons need a stated denominator. Stripe’s declines guidance says to analyze unique declines and exclude failed retries when reviewing authorization rates, because a layer that retries raises the attempt count and moves an unadjusted rate without anything improving. Read the payment result, not the transport: Adyen returns HTTP status code 200 with a message of OK even when an authorization is refused, and its resultCode, refusalReason and refusalReasonCode carry the real outcome.

Source: Stripe, “Declines” (Stripe guidance on measuring authorization and decline rates); Adyen, “Refusal reasons” (Adyen HTTP-versus-payment-result distinction and refusal codes), accessed 2026-09-04.

Continue with Payment Authorization for the approval step itself, and Cross-Border Payment for the cross-border context these routing decisions sit in.