In short: payment gateway feature checklists (PCI compliance, uptime, pricing) no longer differentiate vendors, because every credible provider meets them. What actually determines the right infrastructure for an EMI, PSP, PayFac or acquirer is licence trajectory, merchant evolution, and how merchant payouts and fraud are handled, not a longer list of features.
Imagine a payments landscape where the right infrastructure looks different for every provider building on it, and where that's a feature of the market, not a flaw. Across Europe's licensed payment sector, that landscape is already here. What began as a simple checkout requirement, accepting Visa and Mastercard, has fragmented into something far less uniform: merchant payouts, alternative payment methods, tokenisation, embedded fraud tooling, direct scheme access. The providers pulling ahead aren't the ones with the longest feature list. They're the ones who understood that "the right gateway" was never a fixed answer to begin with.
In our previous article, From EMI to Acquirer: A Strategic Guide to Expanding Payment Services, we examined what it actually takes to build a payment gateway as a card acquirer. This piece asks a different question: why are fewer of Europe's licensed providers letting the answer come from a feature checklist at all?
For years, evaluating a payment gateway meant lining vendors up against a shared set of criteria: PCI compliance, uptime, pricing per transaction, and supported currencies. This worked well enough when payments meant one thing: collecting card details at checkout, and every credible provider could tick the same boxes.
That model is fading. Payments have stopped being a single function and have become a portfolio: inbound collection alongside outbound merchant payouts, card acceptance alongside a growing list of alternative methods, static risk rules alongside real-time fraud scoring. A checklist built for a simpler era can no longer tell two providers apart, because it was never designed to capture what actually varies between them.
What's replacing it isn't a longer checklist. It's a recognition that the right infrastructure depends entirely on the provider choosing it.
Two providers with identical merchant volumes may require entirely different infrastructure, because the variables that matter aren't included any feature comparison. A few stand out:
None of this shows up on a comparison spreadsheet. It shows up in how a provider answers questions about its own trajectory.
It's tempting to treat this growing complexity as a burden, one more reason payments infrastructure is hard to get right. In practice, it does the opposite: it clarifies the decision, rather than complicating it.
Take merchant payouts as an example. Once a provider understands the actual mechanics involved, calculating what's owed, scheduling it, generating bank instructions, and reconciling it against reserves, the build-or-buy question stops being abstract. A team that sees this clearly rarely debates whether to build it from scratch; the operational weight of getting it wrong, quietly, in a finance team's spreadsheets, every settlement cycle, makes the answer obvious. The same is true of fraud, of merchant onboarding, of tokenisation. Understanding the full shape of the problem is what turns an intimidating decision into a straightforward one.
This is visible in how Ginger's own clients operate. Keeping merchant information up to date is historically one of the more manual bottlenecks in acquiring, exactly the kind of operational weight that makes building in-house a bad bet. For a provider like MyTU, it comes down to sharing merchant details once; Ginger creates the merchant across downstream systems like Silverflow, which handle scheme and wallet registration, in the background.
This is the shift worth naming: complexity, properly understood, doesn't work against a provider's decision-making. It sharpens it. Smaller European acquirers have noted publicly that compliance and governance now account for as much as 40 to 50 percent of staff, up from roughly 10 to 15 percent only a few years ago, as regulatory obligations have grown. Infrastructure that absorbs part of that burden changes the calculation considerably.
The providers who will scale cleanly over the next few years won't be the ones who found a vendor with the most features. They'll be the ones who understood their own licence, their own merchants, and their own trajectory well enough to know what “right” actually looked like for them, and who chose infrastructure that could grow alongside that answer rather than requiring a rebuild every time it changed.
Ginger is built around exactly this problem. Direct scheme access through Silverflow, automated merchant enrolment, tokenisation, and merchant payouts sit within a single, API-first platform. Built by XPP, it's designed less as a checklist of features and more as infrastructure that keeps pace as a provider's own definition of “right” keeps evolving. Providers like Xpate, a licensed acquirer building on Ginger's direct integration with Silverflow, are an example of this in practice: expanding merchant services without needing to rebuild scheme connectivity from the ground up.
The market has stopped rewarding the providers with the longest feature list. It's starting to reward the ones who know exactly what they're solving for. For those already in the middle of that decision, How to Choose a Payment Gateway: A Guide for PSPs, Acquirers and EMIs sets out the practical questions worth asking before signing with anyone.
Why don't feature checklists work well for comparing payment gateways anymore?
Because every credible vendor now meets the baseline (PCI DSS compliance, uptime, card acceptance), a checklist of those items no longer differentiates providers. What actually varies is how each platform handles merchant payouts, fraud, tokenisation, and scaling, none of which show up as a simple checkbox.
What should an EMI, PSP or acquirer look at instead of a feature list?
Its own licence and trajectory, how its merchant base is likely to evolve over the next 12 to 18 months, and how much of the acquirer, fraud, and payout relationship it manages directly versus through a partner that handles the underlying complexity.
Is Ginger a payment gateway or something broader?
Ginger is a payment gateway platform for licensed payment providers, EMIs, PIs, PSPs, and PayFacs, that combines card acceptance with direct scheme access, tokenisation, automated merchant enrolment, and merchant payouts in a single API-first platform.
Where can I find a practical checklist for choosing a payment gateway?
See How to Choose a Payment Gateway: A Guide for PSPs, Acquirers and EMIs, which covers build-versus-buy, evaluation criteria, and specific questions to bring into a vendor conversation
