There's No Such Thing as a Bad Payment Provider

“Our payment gateway isn’t working” is one of the most common sentences in early-stage business, and most of the time it’s pointed at the wrong noun.

A gateway is the visible part: the checkout form, the API your engineers integrate against, the thing that either loads or doesn’t. A payment service provider — PSP, and I’ll use “provider” for short — is the business behind it. It holds the banking relationships, it moves the money, and it decides how your transactions reach the banks on the other end. Founders conflate the two constantly, which is a reasonable mistake to make, because the gateway is the only part of the arrangement they ever see or touch.

It matters because the two words point at different fixes. A gateway problem is an engineering problem with a known shape. A provider problem is a commercial and structural one, and it doesn’t get solved by anyone in your team writing better code.

Why “bad provider” is almost never the diagnosis

Here is the position I hold most firmly in this area, and I say it professionally as often as anyone lets me: there’s no such thing as a genuinely bad provider.

I don’t mean every provider is equally good at everything. They aren’t, and the differences are large. I mean that “our provider is bad” is almost never the actual finding, even when it feels obviously true from inside a bad week.

What sits behind every provider is a particular set of banking connections — specific relationships, with specific banks, each carrying its own risk appetite, its own view of your industry, its own behaviour across card types and countries. Two providers offering what looks like an identical service are, underneath, two different routes into the banking system. When approval rates differ between them — approval rate being the share of attempted payments that actually go through — the difference usually has very little to do with the quality of the software you’re looking at, and a great deal to do with which bank is on the far end and what that bank currently thinks about traffic like yours.

That’s also why performance moves without anything on your side changing. A bank revises a threshold. A risk team reviews a category and turns the dial down for a quarter. A sponsoring relationship somewhere upstream ends, and traffic that used to flow through one route gets re-pointed at another. None of this is visible to you. What is visible to you is that the numbers were fine in March and aren’t fine in June, and the nearest available explanation is that the provider has become bad.

A provider that performs poorly for your traffic this month isn’t defective. It’s one specific path through the banking system, behaving the way that path happens to behave right now, for your particular mix of customers, countries and card types. The reason it feels like a verdict on the provider is that you have nothing to compare it against.

That last part is the actual problem. A business running on one provider has no baseline. It can’t tell the difference between a provider getting worse, a bank getting stricter, its own traffic changing shape, and a seasonal effect it sees every year — because all four look identical from a single dashboard. The missing thing isn’t a better provider. It’s a second reading.

Nobody chose to have one provider

It’s worth saying plainly that the single-provider situation is almost never a decision. It’s a residue.

You integrated one provider at the start, because you needed to take money and integrating one was already more work than you wanted. It worked. The business grew around it — the checkout, the reporting, the finance process, the saved cards, the refund workflow, the person who knows how the settlement file is laid out. None of that was a commitment to that provider. All of it functions as one.

Then the second integration never gets scheduled, and the reason is entirely rational at every individual point where it comes up. It costs roughly what the first one cost. It solves a problem that hasn’t happened. It competes for engineering time against features with customers attached to them. Every quarter it loses that argument on the merits, and the accumulated result of winning that argument correctly eight times in a row is a business with one path and no way to see it.

The cost of that shows up only in the month you need it, which is the month you have the least capacity to do anything about it.

What a second path actually buys

Running more than one provider is usually described as redundancy, and redundancy sounds like insurance — something you pay for and hope never to use. That undersells it, because the second connection starts doing useful work immediately, before anything has gone wrong.

It gives you a comparison. The same traffic, on the same days, split between two routes, measured by the only party in the room who isn’t grading their own homework. That’s the only honest way to find out whether a provider is performing well for your specific business, and it isn’t information either provider can give you about themselves.

It gives you the ability to move. Not as a threat, as a fact — volume shifts because you decided it should, not because somebody scheduled a migration project for next quarter.

And it gives you somewhere to send traffic when a route degrades. Providers have outages and bad weeks. Yours will have one, and whether that’s an inconvenience or a genuinely bad day depends entirely on whether the checkout has an alternative to reach for while somebody else’s engineers work the incident.

Orchestration is the layer that makes all of that routine rather than heroic: one integration on your side, several providers behind it, and the routing rules, reporting and customer records living independently of any of them. It’s a narrower thing than the word suggests, and I have written about what it is and isn’t separately.

Where this doesn’t apply

I would rather name the exception than let this sound universal, because the exception is real and I run into it.

If you’re a genuinely single-market, single-product business, and your one provider already covers every payment method your customers actually use, at an approval rate that’s sufficient for your volume, you don’t need any of this. An orchestration layer on top of a setup that’s already working is another abstraction to debug and another thing to monitor, bought against a risk you aren’t currently running. That business exists, and orchestration is the wrong answer for it.

There’s also a smaller fix worth ruling out first, and it applies to exactly that kind of business. Sometimes what looks like poor provider performance is a badly mapped integration — fields passed in the wrong format, or not passed at all, so the bank on the other end is making its decision with less information than it could have had. Correcting that can improve things meaningfully with no second provider and no new layer involved. It’s unglamorous, it’s cheap, and it’s worth eliminating before concluding you need more infrastructure.

The question I would actually ask

If you’re running one provider today and wondering whether that’s a problem, the useful question isn’t whether your provider is good.

It’s what you would do on the morning your approval rate drops four points and stays there. If the answer involves a discovery call, a contract, and an engineering project, then the number on your dashboard isn’t something you manage. It’s something you find out about.

That gap between noticing and being able to act is the part worth paying attention to — it usually has a specific cause, and it’s worth finding before the next drop in your numbers, not after.