Adyen markets built-in smart routing. If you already run Adyen, the natural question is whether Adyen payment orchestration and optimization inside the platform is enough, or whether a separate orchestration layer on top is buying you something Adyen doesn’t already provide. The honest answer depends on what you’re actually optimizing for: cost and approval rate within Adyen’s network, or resilience across more than one.
Adyen’s own routing feature is real, it has published results, and for a single-PSP setup it does what it says. It also has a scope, and that scope is the whole question. This piece covers what Adyen’s routing actually does, where a single-PSP router structurally can’t help regardless of how good its algorithm is, and where the answer to “do I need an orchestration layer” is genuinely no.
What Adyen’s built-in routing actually does
Adyen’s Intelligent Payment Routing launched in September 2024 for US debit card transactions. It selects the acquiring route with the lowest cost and the highest predicted authorization success for each transaction, using AI trained on Adyen’s own transaction history.
Key stat: In its pilot with more than 20 enterprise merchants, including eBay, Microsoft, and 24 Hour Fitness, Adyen reported an average 26% reduction in debit processing cost and a 0.22% average lift in authorization rate, with some merchants seeing cost savings as high as 55% and authorization uplift as high as 1.15% (Adyen, 2024). One merchant recovered $600,000 in the first 30 days.
That feature exists because of a specific regulatory requirement, not general routing ambition. The Federal Reserve’s amendments to Regulation II, finalized in October 2022 with a July 2023 compliance date, require debit card issuers to support at least two unaffiliated networks for card-not-present transactions (Federal Reserve Board). Adyen built network-choice routing to meet that requirement well, and then extended it into a cost and approval-rate optimizer. What it optimizes is which network, inside Adyen’s own acquiring setup, handles a given US debit transaction. It’s payment routing in the fullest sense of the term, applied to one provider’s network.
Adyen’s broader routing claims describe the same scope in different words. Adyen’s own product page states the system will “automatically find the acquiring route with the highest authorization success rate and the lowest cost,” and describes the underlying infrastructure as a “single platform built in-house.” Every route being optimized is a route inside that one platform. There’s no ambiguity to resolve here, because Adyen is describing its own product accurately: the routing is real, it’s not scoped to debit alone, and it still only ever chooses among Adyen’s own acquiring connections.
Where single-PSP routing hits a structural ceiling
Routing logic can only choose among the paths it has access to. Inside one PSP’s acquiring network, that means choosing among the networks and acquiring banks that PSP has relationships with. It cannot choose a different PSP entirely, because a different PSP isn’t a routing option from inside Adyen’s platform. That’s not a criticism of Adyen’s engineering. It’s what “single-PSP routing” means by definition.
Scale Venture Partners frames the practical consequence well: as merchants grow, they go from managing one processor contract to managing many, add payment methods and geographies a single full-stack PSP doesn’t cover natively, and start running into use cases (buy now, pay later, bank-to-bank transfers, region-specific alternative payment methods) that some acquiring networks handle better than others. None of that is a failure of Adyen’s routing. It’s the ceiling that any single provider’s routing hits once your payment needs outgrow what one acquiring relationship can offer.
Multi-PSP routing, the kind that operates across providers rather than within one, is where the gains move from optimizing one network to choosing the best network across several. A router can only choose among the paths it can reach, and a single PSP’s routing engine can only reach that PSP’s own connections, no matter how good the underlying algorithm is.
Multi-acquirer failover: the case a single PSP can’t make for itself
Failover means routing a transaction to a different provider when the primary one is unavailable. A single PSP’s routing engine, however smart, cannot fail over to a different PSP. If Adyen has an outage, incident, or extended latency spike, Adyen’s own routing has nowhere else to send the transaction, because everything it routes to is still Adyen.
Closing that gap is what payment gateway failover means in practice: a second, independent processor that can pick up traffic when the primary one can’t process it. It requires an integration to at least one PSP outside the one experiencing the problem, which by definition sits above any single PSP’s own routing feature, no matter how that feature performs on cost and approval rate day to day.
Vendor concentration risk and portability
Running one PSP’s routing well doesn’t change how much of your payment volume depends on that one PSP. Every transaction still moves through Adyen’s infrastructure, is priced under Adyen’s terms, and is subject to Adyen’s roadmap decisions. That’s not a flaw in Adyen specifically. It’s the structural position of any business on a single processor, and it’s the same position regardless of how good that processor’s own routing is, because routing quality and vendor concentration are separate axes.
Portability compounds the same issue. Stored payment credentials, retry configuration, and routing rules built for Adyen’s platform don’t transfer if you later add or move to a second PSP; that work starts over. An orchestration layer that sits above the PSP layer, rather than inside one PSP, keeps that configuration reusable across whichever providers are connected, so adding a second processor later is a configuration change rather than a rebuild.
When you don’t need a payment orchestration layer
Adyen’s own published guidance on this is direct: orchestration “may offer limited value” for many businesses, and makes sense only “under specific conditions,” specifically when downtime risk materially outweighs the operational cost of running it, and when the business has the resources to manage a multi-layer setup properly (Adyen). Adyen also notes plainly that for many businesses, “the additional complexity can quickly outweigh any marginal gains.”
That’s an accurate description of a real tradeoff, not a hedge. If you run one PSP, have no requirement for failover to a second provider, and aren’t planning to add processors for cost, geographic, or redundancy reasons, an orchestration layer adds a component to maintain without a corresponding problem for it to solve. Single-PSP merchants with no failover requirement are not who this category is built for, and the honest version of this article says so before it says anything else about when you should add one.
How a third-party orchestration layer sits alongside Adyen
None of this makes Adyen and an orchestration layer competing choices. Orchestra’s own Adyen integration treats Adyen as a network member, not a replacement: high-value enterprise transactions can route to Adyen specifically, while other transactions route to cost-optimized or region-specific processors, all through one integration rather than separate API connections per provider.
The division of labor is straightforward:
| Dimension | Adyen’s built-in routing | Third-party orchestration layer |
|---|---|---|
| Optimizes for | Cost and approval rate within Adyen | Cost, geography, performance, or a hybrid, across every connected PSP |
| Scope | Adyen’s own acquiring network only | Every connected PSP, Adyen included |
| If Adyen has an outage | No alternative route available | Fails over to a different PSP automatically |
| Adding a second PSP | Not applicable, single-PSP by design | Configuration change, not a rebuild |
Both operate on the same transaction stream. Neither replaces the other (Orchestra, payment-routing-optimization).
They answer different questions, and running both isn’t redundant: it’s the same layering that a debit network-choice requirement created inside Adyen’s own platform, applied one level up, across 130+ connected PSPs instead of within one.
Deciding what your stack actually needs
The decision comes down to what’s actually driving the evaluation, not a general sense that more optimization is always better:
- If the concern is squeezing more cost or approval-rate performance out of Adyen specifically, Adyen’s own routing already does that, and adding a layer on top for the same job is redundant.
- If the concern is what happens when Adyen itself has an outage, a single PSP’s routing cannot answer that question, because failover requires a second PSP by definition.
- If the roadmap includes a second processor for geographic coverage, cost competition, or better negotiating terms, that configuration lives more cleanly in an orchestration layer than rebuilt per PSP.
- If none of the above apply today, but the business is entering new markets, adding payment methods, or growing past the point where a single vendor relationship is comfortable, the switch signals are worth tracking even if the answer today is not yet.
Adyen’s routing and a third-party orchestration layer aren’t in tension. One is a feature of a PSP. The other is the layer that decides whether that PSP, or a different one, handles the transaction at all.
Frequently asked questions
Does Adyen have built-in smart routing?
Yes. Adyen’s Intelligent Payment Routing analyzes transaction-level signals to route payments for cost and approval-rate optimization, currently scoped to US debit card transactions within Adyen’s own acquiring network (Adyen, 2024).
If I’m on Adyen, do I still need a payment orchestration platform?
Not always. If you run one PSP, don’t need multi-acquirer failover, and aren’t planning to add processors, Adyen’s native routing may be enough on its own, by Adyen’s own description of when orchestration is and isn’t worth the added complexity. The need for an orchestration layer shows up once you require redundancy across PSPs, not just optimization within one.
What can Adyen’s routing not do that a third-party orchestrator can?
Adyen’s routing optimizes within Adyen’s own network. It cannot fail over to a different PSP if Adyen itself has an outage, and it cannot route to a processor Adyen doesn’t own. A third-party orchestration layer sits above multiple PSPs, including Adyen, and can shift volume across providers when one is unavailable or underperforming.
Is using a payment orchestration layer on top of Adyen redundant?
No. They operate at different scopes. Adyen’s routing optimizes transactions inside its own acquiring network. An orchestration layer decides which PSP handles a transaction in the first place, including failover to a non-Adyen processor. The two are complementary rather than duplicative.
What’s the risk of relying on one PSP’s built-in routing alone?
Vendor concentration. Every transaction depends on one provider’s uptime, pricing, and roadmap, and an outage or a pricing change affects all of it at once. Moving off that PSP later means rebuilding routing configuration from scratch rather than reassigning traffic to an already-connected alternative.
When should a merchant add a payment orchestration layer to an existing Adyen integration?
When the business needs multi-acquirer failover, is adding a second PSP for cost or geographic coverage, or wants routing configuration that stays portable rather than tied to one provider’s platform. Single-PSP merchants with no failover requirement don’t need this yet, and Adyen’s own guidance agrees.
