Every other module in this course optimizes something inside the authorization path: the funnel, local methods, tokenization, routing, 3DS. Orchestration is the layer that sits across all of them and decides who runs what. It is also the one decision where the wrong answer quietly taxes every transaction you process, because an orchestration layer is, by definition, another hop between your checkout and your acquirer.
So the question is not "is orchestration good." Routing across PSPs, failing over when one degrades, and keeping a portable token vault are real wins. The question is whether you buy that capability, build it, or stay single-PSP a while longer. This lesson is about pricing each path honestly.
What orchestration actually buys you
Strip away the marketing and an orchestration layer does four concrete things: it abstracts multiple PSPs behind one integration, it routes each transaction by rules you define, it fails over when a processor times out or starts declining, and it holds payment credentials in a vault that is not owned by any single processor.
The vault point is the one most teams underrate. When card data lives inside one PSP's vault, moving to a second processor means a card-data migration, which is slow, PCI-scoped, and entirely at your incumbent's mercy. A neutral vault with a portable, acquirer-agnostic token format is what makes everything else in modules 5 and 6 (routing and exemptions) executable rather than theoretical.
The benefits are also the reason single-PSP shops feel the pain first. If your one processor has a bad night, you have no second rail. Orchestration's core promise is that failover happens in milliseconds and is invisible to the shopper.
The hidden cost: an extra hop
Here is the part vendors gloss over. Every request now travels checkout, then orchestrator, then PSP, then network, instead of checkout, then PSP, then network. That added segment has a latency cost and a dependency cost.
On latency, the rough industry rule is that each additional 100ms of checkout latency shaves around 1 percent off conversion. A well-engineered orchestration layer should add on the order of 50 to 100ms to the full payment flow. That is acceptable when the routing and failover it enables recover more conversion than the hop costs, and unacceptable if the layer is poorly built or you are not actually using its routing.
On dependency, you have inserted a new single point of failure in front of all your PSPs. The defense is the same circuit-breaker logic the orchestrator uses on processors: short timeouts, a direct fallback path to a default PSP if the orchestration API itself is slow, and synchronous health checks. If your orchestrator goes down and you have no bypass, you have centralized risk instead of distributing it. Insist on seeing the provider's failover architecture and historical uptime, not a number on a slide.
The make-vs-buy framework
Three variables decide this: volume, the number of PSPs and methods you genuinely need, and how much payments engineering you want to own.
When to buy
Buy when you need multi-PSP routing, network tokens, and local methods live in weeks rather than quarters, and when payments is not a function you want to staff as a permanent team. Building a credible orchestration layer in-house is commonly framed as a multi-million, 12-to-18-month effort before you have parity with a vendor, and that is before ongoing maintenance of every PSP API change.
The trade is cost per transaction and some loss of control. Commercial platforms typically charge a per-transaction orchestration fee, often cited in the range of roughly $0.01 to $0.10 on top of your PSP fees, sometimes structured as a monthly platform fee plus a smaller per-transaction component. Most do not publish numbers, so model your real volume against a quoted rate before signing. Our Primer review walks through one no-code option in this category.
When to build
Build when you are at the volume where per-transaction vendor fees exceed the fully loaded cost of an in-house team, when your routing logic is a genuine competitive edge, or when regulatory and data-residency requirements force you to own the vault. At very large scale, a few cents per transaction is a real line item, and the math can flip.
The cost of building is not the first version. It is owning PSP integrations, network-token lifecycle, account updater plumbing, and the on-call rotation that keeps the layer from becoming the outage. That is module 10's instrumentation problem multiplied across every processor.
When to do neither yet
If you run one PSP, process modest volume, and have no near-term need for a second acquirer or a new market, orchestration is premature. You would be paying the extra hop without using the routing that justifies it. The right move is often to negotiate a clean exit and portable tokens with your current PSP now, so that when you do add a layer, migration is cheap.
A worked example
Take a merchant processing $500 million a year, roughly 12 million transactions at an average ticket of about $42.
Buy path: at a representative $0.05 per-transaction orchestration fee, that is about $600,000 a year. If routing and failover lift authorization by even 1 percentage point, that is roughly $5 million in additional captured volume. The hop pays for itself many times over, provided the lift is real and measured, not assumed.
Build path: assume a team of six engineers plus infrastructure, call it $2 million a year fully loaded, and 12 to 18 months to parity. You only beat the buy path on direct cost if your volume pushes vendor fees well above $2 million, which at $0.05 means north of 40 million transactions. Below that, you are buying control, not savings, and you should be honest about which one you actually need.
The discipline is to put both numbers on the same page and refuse to let "we could build it" stand in for "we should."
Takeaway
Orchestration is an architecture decision with a per-transaction tax, so treat it like one. Buy when speed and breadth matter more than the fee, build only when scale or sovereignty makes the math and the control worth a standing team, and stay single-PSP until you will actually use the routing the extra hop buys. Whatever you choose, own a portable token vault and a direct fallback path. Those two things keep orchestration from becoming the lock-in and the outage it was supposed to remove.