Most teams frame this decision as a feature comparison. They build a spreadsheet of PSPs, score them on supported methods and pricing, and pick a winner. That is the wrong starting point. The real decision is about where you want your engineering team to spend the next three years, and how much of your compliance scope, your fraud liability, and your processing economics you are willing to own.
Build, buy, and orchestrate are not three points on a quality spectrum where orchestrate is "more advanced." They are three different commitments. What separates them is a set of questions about scope and cost, not the vendor logos.
The three options, defined precisely
Build means you integrate directly with acquirers and card networks, run your own gateway logic, and hold the merchant-of-record and compliance burden yourself. Almost no one ships a product this way at the start, and most teams that think they want to actually want one of the next two.
Buy means you integrate a single payment service provider that bundles acquiring, processing, tokenization, and risk into one API. Stripe, Adyen, and Braintree sit here. You write to one integration and inherit their economics, their uptime, and their declines.
Orchestrate means you put a routing layer between your application and multiple PSPs or acquirers, so each transaction can be sent to the best provider by cost and geography. This is middleware, not a processor. You still need underlying PSPs; orchestration decides which one each transaction hits.
The market has matured past "connect to multiple PSPs and route." Some orchestration vendors are pure connectivity layers, while others bundle orchestration with their own financial infrastructure, which blurs the line between buy and orchestrate. Read the contract, not the marketing.
Question 1: Is one PSP actually failing you, or do you just fear lock-in?
Orchestration solves real problems: declining approval rates as you expand into new markets, FX markup on cross-border volume, and single-vendor outage risk. Routing a cross-border transaction through a local acquirer in the issuer's country can avoid the PSP's FX markup, which in our experience frees up somewhere on the order of a few tenths of a percent to a percent or so of cross-border revenue.
But none of that helps you if you process in one currency, in one region, with healthy approval rates. In that case orchestration adds a layer of latency, a second reconciliation surface, and a vendor to manage, in exchange for resilience you may not be exercising. Fear of lock-in is not the same as a measured cost from lock-in. Quantify the second before you pay for the first.
In our experience, teams processing under roughly a million dollars a year rarely recover the integration and operational cost of orchestration. The savings scale with volume; the overhead does not.
Question 2: What compliance scope are you signing up for?
This is the question most product roadmaps skip, and it is often the one that should decide the whole thing. Where card data touches your systems determines your PCI DSS Self-Assessment Questionnaire, and the gap between tiers is large.
If you fully redirect or use a PSP-hosted iframe so card data never touches your domain, you qualify for SAQ A, which is roughly 22 requirements. The moment any element of the payment page originates from your own domain, even an iframe you serve, you are at SAQ A-EP at minimum, which is roughly 191 requirements. If you accept or store card data on your own systems, you are at SAQ D, the full standard at roughly 329 requirements.
There is a newer wrinkle that hits anyone serving the payment page. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025. Together they require you to inventory and authorize every script on your payment page, verify script integrity, and run tamper detection on the page as received in the consumer's browser. If you self-host the form, that script inventory is now your standing obligation, refreshed continuously.
The practical read: "build" and parts of "orchestrate" can quietly drag you up the SAQ ladder and into client-side script monitoring. A clean PSP-hosted integration keeps you near the floor. Decide whether owning that scope buys you anything you actually need.
Question 3: Can your team carry the operational surface?
Every option you add multiplies the things that can break at 2 a.m. A single PSP gives you one reconciliation file, one webhook format, one settlement schedule, one support relationship. Orchestration gives you several of each, plus the routing logic itself, which is now a piece of payments-critical code you own and must test against the unhappy paths from Module 2.
That cost is real but bounded, and a good orchestration vendor absorbs some of it by normalizing data and webhooks for you. The question is whether you have the on-call maturity and the observability (Module 9) to run a multi-provider estate before you have a multi-provider problem.
A worked example
A subscription company processes $40 million a year, 70 percent domestic in USD, 30 percent across the EU and UK. On a single PSP they see EU approval rates around 86 percent against 94 percent domestic, and they pay an FX markup on every cross-border charge. The approval gap alone, at 30 percent of $40 million, is roughly $960,000 of attempted volume failing that a local EU acquirer could likely recover a chunk of.
For them, orchestration pencils out: the recovered approvals and avoided FX comfortably exceed the integration and operating cost, and they already serve their own checkout, so they are at SAQ A-EP regardless. The scope decision is already made; the routing decision is where the money is.
Flip one variable. If that same company were 100 percent domestic at $3 million a year, the math collapses. They should buy one PSP, use the hosted fields to stay at SAQ A, and put the saved engineering time into the ledger (Module 4) and reconciliation (Module 6).
The takeaway
Do not choose by feature list. Choose by answering three questions in order: is a single PSP measurably failing you, what compliance scope does each option force you to own, and can your team operate the surface area you are adding. Run the numbers on approval rates, FX, and outage cost against integration and operational overhead. If the spread is small or uncertain, buy one PSP and revisit when volume or geography makes the gap unmistakable. Orchestration is a tool for a problem you can name and size, not a default for products that want to look sophisticated.