One gateway is right for longer than anyone selling you a layer will admit
If you sell in one country, in one currency, through a provider you are happy with, a single gateway is not a compromise — it is the correct architecture, and adding anything on top of it is complexity you are paying for and not using. This page is about the three specific moments when that stops being true, and what your options honestly are when it does. If the terminology is new, what payment orchestration is defines it first; this page assumes you have that and asks whether you need it.
What a single gateway is genuinely good at
Worth stating plainly, because most comparison pages skip it. One provider means one SDK, one dashboard, one support relationship, one set of error codes to learn, and one place to look when something is wrong. Documentation from the large providers is genuinely excellent. You can be taking money in an afternoon.
None of that is a trap, and none of it is a reason to add a layer. The reason to look further is not that a single gateway is bad. It is that a single gateway makes one assumption — that this provider can take every payment you will ever want — and that assumption expires in a predictable way.
Three moments that change the answer
Nearly every team that outgrows one provider does it at one of these. Two you can see coming.
A market you cannot serve
Your provider will not settle the currency, or does not offer the method the market actually uses. The customer is willing to pay and cannot. No amount of optimising your existing provider fixes this one.
An outage with a number on it
Downtime stops being an inconvenience the first time you can express it in revenue. That is the point at which "we have one provider" turns from a simplification into a risk you are carrying deliberately.
A hold you did not expect
A risk review, a volume spike, a reserve. This is the one nobody plans for, it has nothing to do with engineering, and it takes 100% of your revenue with it for as long as it lasts.
The third is why this decision has a timing component at all. The first two give you notice; the third does not, and it is the worst possible moment to start a payments migration — which is the argument for making the change while nothing is wrong.
The four honest options
When one provider stops being enough there are four routes, and they are genuinely different trades rather than four brands of the same thing.
1. Switch to a different single provider
Sometimes correct, and often underrated. If your problem is one market and a competitor covers both it and your existing one, moving is simpler than layering. Adyen and Checkout.com are built for exactly this — broad international coverage under one contract. The catch is that you have paid a migration cost to arrive at the same architecture, and the assumption that broke will break again with a different market. Switching without losing sales covers how to do it safely if this is your answer.
2. Add a second direct integration
The intuitive move, and the one that costs the most over time. Two providers is not twice the work — it is twice the integration plus a third system nobody scoped, the one that decides which provider a payment goes to, keeps one identity for a payment across both, reconciles them, and gets updated whenever either provider changes an API. That coordinator is a product, and building it is discussed in how failover is actually built.
3. Move to a merchant of record
Paddle, Lemon Squeezy and Polar become the legal seller of your product. They take on sales tax and VAT registration, invoicing and compliance, which for a small team selling digitally into many countries is a real and sometimes decisive benefit. The trade is equally real: they own the customer relationship and the payment rails, their percentage is meaningfully higher, and you have replaced one dependency with a deeper one. If what you actually want is someone to handle tax liability, an orchestration layer is the wrong tool and a merchant of record is the right one. PaymentHood is not a merchant of record and does not pretend to be.
4. Put a layer above the providers you already have
Orchestration — PaymentHood, Primer, Spreedly and others. Your application integrates once with the layer; the providers sit behind it and you keep your own accounts, your own contracts and your own negotiated rates. Adding a provider becomes configuration rather than a project, and the coordination problem from option two is the product you are buying rather than the code you are writing.
The trade here is honest too: it is another dependency in your payment path, and it is worth asking any orchestration vendor what it costs per transaction, because several charge a percentage on top of your provider's fees. That is the question that decides whether the layer pays for itself.
Counting the cost properly
The comparison people run is layer fees against zero, which makes a single gateway look free. It is not free; its costs are just distributed somewhere nobody invoices you for.
- Engineering time — every provider added the direct way, plus the coordination code between them, plus maintenance as APIs change.
- Sales that never happened — customers in markets you cannot take money in, and the ones who abandoned because their method was missing.
- Approval rate — a few percent of legitimate payments declined for routing reasons, which is silent and adds up. Improving approval rate puts numbers on it.
- Outage exposure — hours of total revenue stoppage multiplied by however often your provider has a bad day.
- Concentration risk — the cost of a hold, which is not gradual. It is everything, until it is resolved.
Run that comparison and the answer for a single-market business is usually still the single gateway. Run it for a business selling into several countries and it usually is not. The point is to run it rather than assume either way.
Where PaymentHood fits
PaymentHood is option four, with the per-transaction question answered up front: no percentage and no per-transaction fee at any volume. You pay only your chosen provider's processing fees, every provider account stays contracted in your name, and funds settle directly from the provider to you — PaymentHood is not a processor, an acquirer or a merchant of record, and never holds your money. The only paid plan is Premium at $29 a month for white-label checkout branding.
Practically, that means you can keep the provider you have. Add PaymentHood above it, connect a second provider when a market or an outage makes the case, and your checkout code does not change either time. For stores on WooCommerce, WHMCS or Joomla the integration is a free plugin rather than a development project.
Make the change while nothing is broken
Create a free account, connect the provider you already use, and add the second one whenever you need it.