In short: choosing a payment gateway isn't really about comparing feature lists. It's about matching infrastructure to your licence, your merchant base, and how much of the payments stack, including merchant payouts, fraud, and scheme access, you want to own directly. This guide covers the real alternatives, what actually differentiates vendors, and the questions worth asking before signing with anyone. For the broader context behind this shift, see Beyond the Feature Checklist: Choosing Payment Infrastructure That Fits.

‍

You're a PSP, acquirer, PI, or EMI, typically in a start-up or scale-up phase, looking to offer merchant services to your own customer base. Some organisations already have a base of business customers and see an opportunity to add payment acceptance as a product. Others are building this as the business itself, from the ground up. Either way, the decision in front of you looks like a simple vendor choice, but it sits closer to a question of what infrastructure you build your merchant services business on.

‍

That distinction matters more than it used to. A gateway traditionally meant one thing: collecting money from a customer at checkout. Providers in this space increasingly also need to move money out, handling merchant payouts, disbursements, and settlement on the other side of the transaction. When both inbound and outbound flows are required, the decision is no longer about a simple checkout tool. Instead, it becomes an evaluation of the foundational infrastructure that allows a provider to operate completely as a PSP or acquirer, without needing to develop one from scratch.

‍

Getting this right tends to show up in three places:

• Providers scale into new markets and payment methods without being forced to re-platform each time, providers can seamlessly expand into new geographic markets and payment methods.
• Engineering and operations teams get back time that would otherwise go into manual integration and admin work.
• Finance teams stop carrying out reconciliation and merchant payouts by hand every settlement cycle.

This guide sets out how to think through the decision with those outcomes in mind, rather than working from a feature comparison alone.

Getting Clear on Your Own Situation

Most evaluations start with a vendor list. They work better starting with a clear picture of the business doing the evaluating.

• Licensing shapes what's technically available, and that shape is shifting. If you're an EMI or PI, you already hold the core infrastructure an acquirer needs, so there's rarely a good reason to route through a third-party acquirer instead. The real fork is between becoming your own acquirer directly, with scheme access through a processor like Silverflow, or operating as a PayFac, a sub-merchant aggregator sitting under someone else's acquiring licence, which trades control and margin for a simpler start. With PSD3 and the Payment Services Regulation set to merge the EMI and PI categories over the next few years, knowing which of these paths you're heading toward narrows the field considerably.

• Merchant needs evolve. Visa and Mastercard acceptance covers most providers at the start, but alternative payment methods, including the fast-growing account-to-account and Pay by Bank rails driven by the EU's Instant Payments Regulation, along with fraud tooling, subscriptions, and multi-currency processing, tend to become requirements faster than expected. Infrastructure chosen to solve only today's needs is one of the more common reasons providers end up re-platforming within a couple of years.

• Speed to market and long-term control pull in different directions, and most providers are weighing both at once. A team that needs its first merchant live within weeks will evaluate differently than one building a multi-year roadmap for thousands of merchants.

• Ownership is largely already decided by the fact that you're reading this. Building or buying your own gateway means holding the commercial relationships with acquirers, alternative payment method providers, and fraud vendors yourself, rather than handing them entirely to a processor. What varies is how much of that relationship you manage directly versus through a partner that handles the underlying complexity for you.

None of these questions has a universally correct answer. They determine what a provider should actually be shopping for.

The Real Alternatives

There are, in practice, a handful of paths, and they're not as interchangeable as a comparison spreadsheet makes them look.

• Established, enterprise-grade gateways are mature and well-tested, built for large-scale acquirers and processors. They tend to be robust but rigid, designed for a different pace of change than most early-stage or scaling providers need.
  

• Smaller, leaner gateways are quicker and cheaper to get started with. Architecture and support depth can become a constraint once merchant volume or complexity grows.
  

• Building a gateway from scratch offers the most control, along with the most responsibility. It's a legitimate path, and one worth understanding properly before ruling it in or out.

A note on what's not on this list: full-stack processors like Adyen, Stripe, Mollie, or Klarna are the right choice for a business that wants to accept payments for itself. They're not an alternative path for a PSP, EMI, PI, or acquirer aiming to offer merchant services to others. If that's your ambition, they're closer to competitors than vendor options, since they hold the merchant relationship, brand, and commercial terms themselves.

‍What Building It Yourself Actually Takes

We've written in detail elsewhere about what building a gateway as a card acquirer involves end-to-end, from onboarding and KYC through merchant configuration, integration methods, the full payment lifecycle, fraud, and the operational tooling underneath it all. Anyone seriously weighing that path should read ”From EMI to Acquirer: A Strategic Guide to Expanding Payment Services”.

‍

The short version is that it isn't one project. It's several running in parallel, spanning engineering, compliance, fraud, sales, and legal resourcing across multiple quarters. This isn't hypothetical: 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. That doesn't settle the build-versus-buy question on its own. It does mean the more relevant question isn't whether building is possible, but whether it's the best use of a team's time over the next year and a half, set against how much of it already exists to buy.

Table Stakes Versus What Actually Matters

Once a provider has decided to buy rather than build, the most frequent pitfall is assessing vendors based on features that are virtually identical across all options. PCI DSS compliance, Visa and Mastercard acceptance, a hosted checkout page, and reasonable uptime guarantees are worth confirming, but they don't distinguish one credible vendor from another, so they shouldn't take up much evaluation time.

‍

What actually separates outcomes:

• Infrastructure ownership. A single-tenant, regionally hosted platform instance keeps a provider's data, infrastructure, and processes entirely separate from other customers, which matters more than it sounds. On shared environments, even white-labelled ones, the underlying provider's branding can surface during checkout, and that kind of inconsistency at a sensitive moment erodes trust and costs conversion.
  
  
• Direct scheme access. Connecting to Visa and Mastercard through a modern processor instead of through layers of aggregation brings lower latency and full visibility into transaction data, instead of that data disappearing into someone else's system.
  

• Real PCI scope reduction. Tokenisation should measurably shrink a provider's PCI scope and its merchants', whether it happens in the gateway vault, at the network level, or both, and not simply appear as a line on a data sheet.
  

• A genuinely layered fraud model.  A serious fraud setup screens every transaction before authorisation and returns a decision, a reason, and a risk score, not just a pass or fail. Providers should be able to choose a setup matching their own risk appetite and adjust it through an admin portal, without needing custom development every time a rule changes.
  

• Merchant payouts that don't drain finance. The majority of manual work in acquiring usually lies with finance rather than engineering. Reconciliation, reserve management, and generating bank payment instructions are the kind of work that quietly consumes a finance team's time every settlement cycle, often through spreadsheets rather than any real system. Automated calculation, scheduling, and execution of merchant payouts, with reports and bank payment instructions generated automatically, lets a provider keep full visibility and control over merchant balances and timing without carrying the manual load.

• Integration flexibility. Hosted pages, host-to-host, web and mobile SDKs, and plugin support mean no merchant is locked into a single integration pattern — there's a route to match any level of technical maturity.

• Automated merchant enrollment. Creating a merchant in the downstream systems that handle scheme and wallet registration, such as Silverflow, should be a single action tied to onboarding, not a manual, repeated task for an operations team.

• What happens after go-live? This is often overlooked in the evaluation itself. Some vendors hand over documentation and step back. Others stay engaged through acquirer relationships, merchant enrolment, and the changes that come with scaling.

Choosing the Right Partner: Questions Worth Asking

A handful of questions tend to surface the real differences between vendors once the table-stakes comparison is out of the way.

‍

On merchants and integration:

• How automated is merchant creation in the downstream systems that handle scheme and wallet registration, and how much still falls to an internal team?
• What transaction types are supported out of the box, and how is tokenisation handled?
• Can we add a new payment method, market, or fraud provider without a migration?

On risk:

• When a transaction is screened for fraud, does the response include a decision, a reason, and a risk score, or only a yes or no?
• Can providers or rules be changed without custom development?

On finance:

• How much of the merchant payout calculation, scheduling, and reporting is automated, versus how much would still sit with an internal finance team?
• What pricing models are supported, and how are reserves and negative balances handled?

On the relationship itself:

• What does the admin portal offer an internal team, and what does the merchant portal offer customers?
• What does the relationship actually look like six months and two years after go-live? This is a fair proxy for what a partnership will feel like once the initial sale is behind everyone.

Final Thoughts

The providers who get this decision right tend to be the ones who worked out their own licence, merchant base, and growth trajectory before they started comparing vendors at all. For many, partnering with a platform that already handles much of this complexity meaningfully reduces both time-to-market and ongoing operational load.

‍

Ginger is built for exactly this. Its API-first platform improves approval rates, and supports advanced transaction types. Built-in tools, including merchant enrolment, hosted checkout, and merchant payouts, let providers focus on scaling their merchant services rather than on integration complexity, and new capabilities can be added to an existing stack without migration or disruption. Ginger combines this with direct scheme access through Silverflow, so scaling a merchant services business doesn't mean scaling the integration work behind it.

‍

Whichever path a provider chooses, build, buy, or something in between, the decision that holds up is the one that matches where the business is actually heading, not just where it stands today.

‍

If you're working through this decision, [get in touch](https://www.xpp.nl/contact) and we're happy to talk through what a well-architected setup looks like for your business specifically.

Frequently Asked Questions

Should an early-stage EMI or PSP build or buy a payment gateway?

It depends on whether building payments infrastructure is the best use of a team's engineering time over the next year to eighteen months. Building gives full control but requires resourcing across engineering, compliance, fraud, sales, and legal in parallel. Buying trades some of that control for speed, provided the platform offers real scheme access, automated merchant enrolment, and merchant payouts rather than a bare checkout page. 

‍

Is a full-stack processor like Stripe or Adyen an alternative to a payment gateway like Ginger?

Not if your ambition is to offer payment services to your own merchants. Stripe and Adyen are built for a business that wants to accept payments for itself. A payment gateway like Ginger is built for a PSP, EMI, PI, or acquirer that wants to offer payment services to others. If that's your goal, Stripe and Adyen aren't a vendor option, they're competitors serving the same merchants you're trying to serve.

‍

What should I ask a payment gateway vendor before signing a contract?

At minimum: how automated is merchant creation in downstream systems like Silverflow that handle scheme and wallet registration, what transaction types and tokenisation are supported, whether fraud screening returns a decision, reason, and risk score, how much of merchant payout calculation and reconciliation is automated, and what the relationship looks like six months and two years after go-live.

‍

Does Ginger support merchant payouts as well as card acceptance?
Yes. Ginger handles both inbound card acceptance, including tokenisation and network tokenisation for approval rates, and outbound merchant payouts, including automated calculation, scheduling, and bank payment instructions.

‍

Ready to talk it through?

If you're working through this decision, we're happy to talk through what a well-architected setup looks like for your business specifically.

‍