Why I Stopped Recommending Single-Gateway Setups in 2026
Julian Reed4 min read·Just now--
For most of my career, I gave merchants the same advice. Pick one payment processor. Integrate it well. Don’t fragment your stack before you have the revenue to justify the complexity.
I was right then. I’m not sure I’d give the same advice now.
The payment landscape has shifted over the past three years. Not because of one big event, but a hundred small ones. The default architecture I used to recommend has slowly become a liability for any merchant doing meaningful volume. And the case for diversifying payment infrastructure, which used to be a problem for scale-stage companies, has moved upstream to almost everyone.
Here’s how I got here.
The case for single-gateway used to be airtight
In 2019, if you were processing under $10M annually, integrating with more than one gateway was almost always a mistake. The reasoning was straightforward:
- One integration meant one set of webhooks, one reconciliation flow, one settlement schedule.
- Modern gateways had become full-stack. They handled tokenization, 3DS, network tokens, dispute management. You weren’t just buying a connection. You were buying an operating system.
- Auth rate differences between top processors were small enough that switching couldn’t justify the engineering cost.
- Most merchants weren’t sophisticated enough to actually use routing logic. They’d set it up, never tune it, and end up with a worse outcome than a clean single-vendor stack.
All of this was true. Some of it still is. What changed isn’t the math — it’s the inputs.
Three things broke the model
Authorization rates stopped converging. Five years ago, the gap between the best and worst processors for, say, a US card on a SaaS subscription was maybe two percentage points. Today, depending on the BIN, the issuer, the MCC, and the country, that gap can stretch into double digits. Issuer-acquirer optimization (the unglamorous work of matching the right acquirer to the right card portfolio) has become the single biggest lever in payment performance, and you can’t pull it with one gateway.
Geography fragmented. A decade ago, “global payments” mostly meant Visa, Mastercard, and a couple of local schemes. Now it means iDEAL, Pix, UPI, PayNow, Bizum, Blik, OXXO, and another forty rails I’m not going to list. No single gateway handles all of them well. Some are excellent in Europe and weak in LATAM. Some are strong in APAC and have no real presence in Brazil. Pretending otherwise costs you conversion in every region you don’t fit.
Downtime became a P&L event. The 2022 Stripe outage was a wake-up call for a lot of finance teams. So was every smaller, less-reported outage since. When your gateway goes down for forty minutes during a flash sale, “we have a great relationship with our processor” doesn’t recover the revenue. The cost of a single point of failure used to be theoretical. Now it shows up in board decks.
What modern merchants are actually doing
The merchants I work with who handle this well aren’t running ten gateways in parallel. That’s the strawman version of multi-processor setups, and it deserves the criticism it gets. Operationally it’s a nightmare.
What they’re doing instead looks more like this:
- A primary processor for the bulk of volume in their core market.
- A secondary processor that handles a specific job: a regional market, a higher-risk card type, or failover for when the primary is degraded.
- Some form of routing layer between their checkout and the processors, sometimes built in-house, more often these days bought.
- A reconciliation flow that treats the processors as interchangeable data sources rather than separate systems.
This isn’t a “multi-gateway” setup in the old sense. It’s a single payment stack that happens to terminate in more than one acquirer. The merchant interacts with one API, one dashboard, one reporting layer. The processors underneath are an implementation detail.
The shift in framing matters. When people argue against multi-processor setups, they’re usually arguing against an architecture from 2015 where you’d have two parallel integrations and manually decide which to send traffic to. That architecture is bad. Almost no one is building it that way anymore.
The honest tradeoffs
I’ll be direct here, because the case for orchestration gets oversold by people with something to sell.
Adding a second processor doesn’t automatically improve your auth rate. If you don’t have the data to know which processor performs better for which segment of your traffic, routing logic is going to make things worse before it makes them better. The merchants who win with multi-processor setups treat it as an analytics problem first and a routing problem second.
There’s also a real cost to reconciliation when you split volume across acquirers. Settlement timing differs. Fee structures differ. Refund flows differ. If your finance team isn’t ready for that, you’ll create more pain than you solve.
And for genuinely small merchants, under a few million in annual volume, the case for single-gateway is still strong. The complexity tax doesn’t pay back.
Where I think this goes
The interesting question isn’t whether multi-processor setups are right for most merchants today. It’s whether single-gateway will be defensible for any merchant doing more than $10M in five years.
My bet is no. Not because every merchant will be running sophisticated routing logic (most won’t), but because the layer that does the routing is going to keep abstracting upward. The question won’t be “which processors do you use” any more than “which cloud regions does your database span” is a question most engineering teams think about day-to-day. It’ll be invisible infrastructure.
The playbook I was giving merchants in 2019 was the right playbook for 2019. The mistake was assuming it was a permanent answer to a permanent question.
Payments don’t sit still that long.
