Pieter Stal, CEO of XPP, wrote about choosing a payment gateway from the buyer's chair, a decision he made years before he ran the company that builds one. I’ve sat in the other chair. I've built payment gateways from scratch, card-present and card-not-present, and rebuilt Ginger's architecture more than once since.
Having built numerous gateways from scratch for both card-present and card-not-present scenarios, it's consistently underestimated how much effort it actually takes to run the thing once it's live. Every technical and product decision has an impact on the availability and reliability of a gateway.
The build is the part you can estimate. The running of it is the part that doesn't stop.
Plenty of large enterprises and legacy acquirers do big, once-a-quarter updates to "minimise risk." That's exactly backwards. Every change carries risk. You want to keep changes as small as possible and roll them out continuously. Same for patching: you want to patch every security vulnerability continuously, without downtime. The quarterly release model is the design choice that makes reliability unreachable, and it's usually chosen in the name of reliability.
The other half of it: things will go wrong. That isn't a risk to be eliminated, it's a given to be designed for. The system has to recover automatically from the failures you can anticipate, and a team has to be monitoring continuously, on standby to jump in on the ones you can't. Neither substitutes for the other. Automated recovery without people watching means you find out from the merchant. People watching without automated recovery means every incident lasts as long as it takes someone to wake up and log in.
Take card payouts as an example. In our processing flow, the merchant can hook into the transaction lifecycle in real time and get feedback on whether the cardholder has enough balance on their wallet to proceed. Legacy gateways weren't designed in an event-driven manner, and so can't properly support cases like this.
It doesn't show up as a missing checkbox. It shows up as "we can't do that."
Payment infrastructure is usually hard to change. Systems that have been around for decades, patched and duct-taped to support modern use cases.
Our approach: work with the customer to first get the use case working, quick and dirty if needed, 80% of the achievable result for 20% of the effort. Then observe, learn how it should actually be done, and do the complicated work of redesigning it properly, without breaking any existing merchant integration.
That last part is the strong point, and it's the part nobody values until they've been burned by the alternative.
Pieter's regret is what he didn't know the first time he made this decision. From where I sit: ask a vendor to walk you through their last serious incident. Not the SLA, not the uptime figure on the website. The actual bad day. What broke, when they knew, how long merchants were affected, and what changed afterward.
Almost nobody asks this, because it feels impolite in a sales conversation. It's the most useful question on the list. What it tells you is whether there's real incident discipline behind the platform, or just a status page. A vendor who can tell you the story precisely, timeline, blast radius, the fix, and the thing they changed so it couldn't happen the same way twice, is a vendor who runs the system, not just ships it. A vendor who says they've never had an incident is telling you one of two things: they aren't being straight with you, or they haven't been running long enough at real volume to find out. Both should worry you equally.
You're not buying a system that never fails. There's no such thing. You're buying the team that handles it when it does.
For the buyer's-side version of this, see Pieter Stal's piece on why he chose Ginger as CEO of XPP. For the full framework, read How to Choose a Payment Gateway: A Guide for PSPs, Acquirers and EMIs.
Is building a payment gateway from scratch ever the right call?
It can be, but the real cost isn't the build, it's running it reliably, indefinitely. That's the part teams underestimate.
Why do legacy payment gateways struggle to keep up?
Most weren't designed in an event-driven manner and carry years of patches over use cases they weren't built for, which makes real structural change risky.
What should I ask a payment gateway vendor that most buyers don't?
Ask them to walk you through their last serious incident, not their uptime figure. How they answer tells you whether there's real operational discipline behind the platform.
Why does Ginger ship changes continuously instead of on a fixed release schedule?
Because every change carries risk regardless of frequency. Continuous, small releases and continuous patching keep the blast radius of any single change small, instead of bundling it into one big, high-risk event.
