There's No Such Thing as a Bad Payment Provider

Startups say “our payment gateway isn’t working” more often than they say almost anything else about their payment stack, and most of the time the sentence is pointed at the wrong noun.

A gateway is the visible part — the checkout form, the API you integrate against, the thing your engineers actually touch. A payment service provider is the business behind it that actually moves the money, holds the banking relationships, and decides how your transactions get routed to the banks on the other end. Founders conflate the two constantly, because the gateway is the only part they ever see. It’s a reasonable mistake. It’s also the wrong place to be looking when something goes wrong.

The take that surprises people

Here’s the part I say a lot, professionally, because it holds up every time someone tries to argue with it: there is no such thing as a genuinely bad provider. I don’t mean every provider is equally good at everything — they aren’t. I mean that “our provider is bad” is almost never the actual diagnosis, even when it feels true from inside a bad week.

The real problem, nearly always, is having exactly one provider and no redundancy. Every provider has different banking connectivity behind it — different relationships, different risk appetites, different approval behavior on different card types and geographies. A provider that performs badly for your traffic on a Tuesday isn’t defective. It’s one specific path through the banking system, and you’ve built your entire business on the assumption that one path will always be open.

Orchestration is the fix, and it’s a narrower fix than the word makes it sound. It isn’t a smarter gateway with a nicer dashboard. It’s the layer that lets you run more than one path at once, compare them on equal terms, and move volume to whichever one is actually working right now instead of whichever one you integrated with first.

Where this doesn’t apply

There’s a real exception here, and it’s worth naming rather than letting the pitch sound universal. If you’re a genuinely single-market, single-product business, and your one provider already covers every payment method you need at an approval rate that’s actually sufficient for your volume, you don’t need this. Adding an orchestration layer on top of a setup that’s already working is complexity with no job to do. That business exists, and orchestration is the wrong answer for it.

There’s a smaller, less dramatic fix worth knowing about too, for exactly that business: sometimes the entire “problem” is a badly mapped integration field, not a provider limitation at all. I’ve seen setups improve meaningfully just from fixing how data was being passed to a single provider — no second provider, no orchestration layer, just correcting something that was configured wrong from the start. Worth ruling out before assuming you need more infrastructure rather than a fix to what you already have.

The actual value, restated plainly

None of this is about the routing being clever. The value was never in the routing itself — it’s in the optionality that redundancy buys you. The ability to move volume when one path degrades. The ability to compare providers on equal terms instead of trusting whichever one you signed with first. The ability to survive a bad month with one banking relationship because it was never the only one you had.

If you run a business with real payment volume across more than one market or product line, the question worth asking isn’t whether your current provider is good. It’s whether “good” is even a property a single provider, on its own, can actually give you.

See the companion piece on what orchestration is and isn’t, Payment Orchestration Is Not a Fancy Payment Gateway, and the system this thinking runs on at /systems/.