---
title: "Choosing a payment gateway for Magento 2"
description: "A decision framework for payment gateways on Magento 2, Adobe Commerce and Mage-OS: module maintenance, upgrade behavior, Hyvä and headless support, and the local payment methods that decide the shortlist in each market."
author: "Luboš Zápotočný"
published: "2026-08-02"
language: "en"
canonical: "https://zapolu.com/blog/magento-payment-gateways/"
---

# Choosing a payment gateway for Magento 2

Choosing a payment provider for a Magento store is usually framed as
a fee comparison. On Magento the fees are the smaller part of the
decision, because almost every provider decision carries a second
one: whose Magento module you will run. The module lives in your
codebase and renders inside your checkout, and a platform upgrade
either carries it along or stops on it. A payment module is the
third-party code closest to the money on every order.

This post gives a checklist for choosing a gateway, then applies it
to six international providers (Adyen, Stripe, Mollie, PayPal with
Braintree, Klarna, Unzer) and four gateways specific to the Czech,
Slovak and Polish markets (GoPay, Comgate, PayU, Przelewy24). Every
vendor fact was checked against the linked source on August 2, 2026;
where something could not be verified, we say so.

## What to check before you sign

**Who maintains the module, and can you read the code?** Adyen,
Mollie, Unzer and PayU maintain their Magento modules in public
repositories. Stripe publishes only release archives, with the issue
tracker disabled. Klarna and Przelewy24 publish no source repository
at all, despite open-source license labels on their packages. GoPay
and Comgate have no module of their own. The modules on offer are
paid and closed, from third-party vendors. The bundled Braintree
extension's current line has no public source either; Gene's
repository stops at its legacy 4.0.x releases. A public repository
is not a quality guarantee, but it lets you read the diff before an
upgrade instead of relying on the changelog.

**How it has behaved across platform upgrades.** The next section
covers the three failure patterns worth searching for. Where the
vendor has no public tracker, and seven of the ten here do not,
search Magento's own tracker for the module name: both incidents
below were recorded there, not in any vendor's tracker.

**The operational flows behind the checkout.** A redirect module
depends on its asynchronous confirmation: the webhook endpoint, its
signature checks and retries, and what happens to an order whose
customer never returns from the payment page. Refunds are the next
check. Some modules issue them from a Magento credit memo, others
only in the gateway's back office, and the same split runs through
capture on shipment and orders created in the admin. Payment tokens
deserve their own question, because Magento-side subscription
extensions expect
[Vault](https://developer.adobe.com/commerce/php/development/payments-integrations/vault/)
while the local gateways below generally document their own
server-side tokenized recurring. Find out which of the two the
module exposes. In the
Czech Republic, Slovakia and Poland, a payment captured before
shipment can create an advance-invoice VAT obligation, one reason
merchants there configure capture on shipment. Confirm the workflow
with your accountant. The profiles below do not carry these facts.
Most vendors publish them only in module documentation and the
closed modules not at all. Run this check on the modules that make
your shortlist.

**Hyvä support, as the public trackers record it.** Hyvä maintains a
public
[compatibility module tracker](https://gitlab.hyva.io/hyva-public/module-tracker)
for the theme and a separate
[integration tracker](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker)
for Hyvä Checkout, and its documentation
[lists the primary tracked payment integrations](https://docs.hyva.io/hyva-checkout/integrations/available-payment-methods.html).
Each ticket on the checkout integration tracker is labeled Vendor or
Community to show who is responsible for the implementation and
first-line support. Who that is matters as much as whether the
integration exists, because it decides who fixes it when the gateway
ships a breaking release.

**Headless coverage.** Magento's
[`setPaymentMethodOnCart` mutation](https://developer.adobe.com/commerce/webapi/graphql/schema/cart/mutations/set-payment-method)
carries a method code plus a method-specific input object, which the
reference requires for every online payment method. A module without
its own GraphQL layer cannot receive tokenized payment data or
return redirect handling over GraphQL. A headless build then covers
the difference with custom work, usually over REST.

**PCI DSS scope.** Per the PCI Security Standards Council's
[SAQ guidance](https://listings.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf)
(a v3-era explainer; the current v4 questionnaires keep its
redirect-versus-iframe distinction), a full redirect or a
provider-hosted iframe can keep a merchant on SAQ A, the short
questionnaire; payment forms or payment JavaScript served from your
own page mean SAQ A-EP. Under the v4.0.1 eligibility criteria,
explained in
[FAQ 1588](https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/how-does-an-e-commerce-merchant-meet-the-saq-a-eligibility-criteria-for-scripts/)
(February 2025), even an iframe integration requires the merchant
page to be protected against script attacks, or the provider's
confirmation that its solution protects it; a plain redirect stays
the smallest scope.

**The payment methods your market actually uses.** Every gateway
here processes cards. The deciding methods are invoice purchase in
Germany, BLIK depth in Poland, and in the Czech Republic whether the
transfer and cash-on-delivery share justifies a local gateway at
all. The market section below has the numbers and their sources.

**Published pricing, in the currencies you settle.** Adyen, Stripe,
Mollie, PayPal, GoPay, Comgate, PayU and Przelewy24 publish price
lists. Unzer publishes entry-level rates and negotiates volume
pricing. Klarna publishes no European price list, and its total cost
cannot be calculated from public information. Check also whether the
gateway settles in each currency you sell in or converts at its own
rate; the conversion sits outside the headline fee. Much of this is
public:
[Adyen lists 26 settlement currencies](https://docs.adyen.com/account/supported-currencies)
for EU merchants including CZK and PLN,
[Mollie lists 13 payout currencies](https://help.mollie.com/hc/en-us/articles/5546871220370-What-are-multi-currency-payouts),
[PayU settles 1:1 in 11](https://developers.payu.com/europe/docs/get-started/integration-overview/references/),
and
[GoPay documents payout currencies per bank](https://help.gopay.com/cs/tema/mam-platebni-branu/chci-pouzivat-gopay-obchodni-ucet/chci-prijimat-platby-v-dalsich-menach/v-jakych-menach-mohu-prijimat-platby-u-ceskych-a-slovenskych-bank).
[Comgate publishes per-currency payout terms](https://help.comgate.cz/docs/vyplaceni-penez-na-ucet),
and
[Braintree publishes its scheme-currency list](https://developer.paypal.com/braintree/docs/reference/general/currencies),
with each merchant's set agreed at onboarding and extended by
[requesting additional merchant accounts](https://developer.paypal.com/braintree/articles/get-started/currencies).
[Klarna pays out in the transaction currency](https://docs.klarna.com/acquirer/klarna/web-payments/additional-resources/use-cases/consumer-fx/).
The rest publish less: Stripe renders its settlement table
client-side, Przelewy24 states payouts in PLN or EUR, and Unzer
publishes no list.

## What upgrades do to payment modules

Three failure patterns are documented in public trackers and release
notes, and all three are worth checking against any module you
shortlist.

The first is unbundling. Magento's 2.4.4 release notes state:
"With the exception of Braintree, all vendor-bundled extensions have
been removed from the Magento Open Source 2.4.4 code base"
([release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-4)).
Since then, payment modules version independently of the platform,
and a core upgrade no longer implies a compatible payment module.

The second is dependency drift.
[Issue #39989](https://github.com/magento/magento2/issues/39989)
against Magento documents the security patch 2.4.8-p1 downgrading
six `paypal/module-braintree` packages from 4.7.0 to 4.6.1-p5 on
affected installs, through a metapackage constraint that left
composer free to pick either version. In the other direction,
[issue #39803](https://github.com/magento/magento2/issues/39803)
records Klarna's module blocking the 2.4.8 upgrade outright through
a `monolog` version conflict. Adobe closed the issue in eleven days
by pointing stores to Klarna as the extension owner. The fix shipped
in module release 3.3.1: archived captures of the Marketplace
listing still show the pre-fix 3.3.0 on
[May 20, 2025](http://web.archive.org/web/20250520080628/https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
and first show the fixed line on
[June 13](http://web.archive.org/web/20250613064417/https://commercemarketplace.adobe.com/klarna-m2-klarna.html),
so stores with the module were blocked for six to nine weeks after
the April 8 GA.

The third is frontend coupling. The
[Mage-OS 2.2.1 release notes](https://mage-os.org/releases/2026-03-18-mage-os-2-2-1-release/)
revert a reCAPTCHA deferred-loading optimization from 2.2.0 because
it caused reCAPTCHA failures on checkout pages using hosted and
iframe payment forms. Payment modules depend on checkout load order
and script timing, so an unrelated frontend change can break the
payment step at checkout. This is the same coupling that makes Hyvä
compatibility a separate deliverable.

On Mage-OS specifically: its distribution ships the core PayPal
module but not Braintree (verified against the
`mage-os/product-community-edition` metapackage), and none of the
ten providers below states Mage-OS support anywhere we could find.
Mage-OS itself
[claims full compatibility](https://mage-os.org/faq/) with Magento
Open Source extensions, so a module that runs on Open Source is
expected to run there. That expectation rests on Mage-OS's claim,
with no payment vendor's commitment behind it. It is the same for
all ten gateways and belongs to the platform decision, not to the
gateway choice.

## Hyvä changes the shortlist

A [Hyvä](/blog/hyva-vs-luma/) storefront changes the payment
question in one way. With the Hyvä theme alone, checkout can stay on
the stock Luma checkout through the documented
[theme fallback](https://docs.hyva.io/hyva-themes/building-your-theme/luma-theme-fallback.html),
where existing payment modules keep working. The fallback is
configured per route and means maintaining a Luma-based checkout
theme alongside Hyvä. And because it applies only to the configured
routes, the express-payment buttons (Apple Pay, Google Pay, PayPal)
that modules render on product, cart and minicart pages remain on
the Hyvä theme and still need Hyvä compatibility from the module.
[Hyvä Checkout](https://docs.hyva.io/hyva-checkout/devdocs/payments/payment-in-hyva-checkout.html)
is different: order placement moves from the payment method to a
central service, so a payment module's Luma frontend does not run
there. Per Hyvä's docs the module's backend can usually be reused,
and the checkout-facing layer must be built anew. Each provider
needs a dedicated integration. Short of building one, the documented
way around a missing integration is the Luma fallback.

The maintenance arrangements behind those integrations are not
uniform, and Adyen shows why it matters. Adyen wrote its own Hyvä
Checkout module, then ended its maintenance. Its README now opens
with a notice that the integration is no longer officially supported
and will not get new updates
([adyen-magento2-hyva](https://github.com/adyen-examples/adyen-magento2-hyva)).
The Hyvä team took the integration over and released a rewritten
package, `hyva-themes/magento2-hyva-checkout-adyen-payment-v2`,
against Adyen's v10 plugin in March 2026
([handover issue](https://github.com/adyen-examples/adyen-magento2-hyva/issues/140)).
Merchants who chose Adyen partly for its first-party Hyvä support
now depend on the Hyvä-maintained package, on a plugin major version
that requires Magento 2.4.8 or newer.

## The six international providers

**Adyen** maintains
[its Magento plugin](https://github.com/Adyen/adyen-magento2) in the
open under an MIT license and released it forty times across the
parallel v9 and v10 lines in the trailing twelve months, counted
from the repository's releases page. The cost of that pace is a
strict support schedule:
[Adyen's own table](https://docs.adyen.com/plugins/adobe-commerce)
gives each plugin major a fixed window (two years for v10), and
stores on 2.4.4 to 2.4.7 remain on the v9 line, in
security-updates-only mode since May 2026 and ending December 2026.
The v10 line added Magento 2.4.9 and PHP 8.5 support in
[v10.10.0](https://github.com/Adyen/adyen-magento2/releases/tag/v10.10.0)
(March 31, 2026), although the support table and the README still
said 2.4.8 only when we checked; the release notes are the current
record. Headless is covered through documented
[GraphQL support](https://docs.adyen.com/plugins/adobe-commerce/headless-integration/),
and the EU method coverage
[includes iDEAL, SEPA Direct Debit, BLIK, Twint and Bancontact](https://docs.adyen.com/plugins/adobe-commerce/supported-payment-methods/),
with cards rendered as embedded components inside the checkout.
Pricing is [published as interchange++](https://www.adyen.com/pricing)
with per-method fees. Plan for a plugin migration every one to two
years; Adyen's README recommends exactly that.

**Stripe** ships a capable module on a closed process. The
[official module](https://github.com/stripe/stripe-magento2-releases)
is distributed as release archives under Stripe's own proprietary
license, with GitHub issues disabled: there is no public bug
tracker to consult before an upgrade. Releases arrive roughly
monthly, support covers Magento 2.3.7 to 2.4.x with fixes only from
module 4.5.x up
([lifecycle table](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/install)),
and both checkout flows, embedded Payment Element and redirect, are
documented as SAQ A eligible in Stripe's docs, which also cover
[REST and GraphQL for custom storefronts](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/custom-storefront).
We unpacked the 4.6.4 release archive: the GraphQL schema and its
resolvers are in the source, and composer.json requires only PHP 7.4
or later.
Read the
[changelog](https://github.com/stripe/stripe-magento2-releases/blob/master/CHANGELOG.md)
before every upgrade: version 4.6.0 shipped breaking changes for
headless builds, and the 4.6.2 notes state that the stronger
authentication requirements introduced in 4.6 "were causing
decreased checkout conversions" before being relaxed. The Hyvä
Checkout integration is published under Hyvä's own namespace.
Stripe's changelog has mentioned Hyvä once. EU methods include SEPA
Direct Debit, iDEAL, Przelewy24 and Klarna. BLIK is absent from
[the module's documented method list](https://docs.stripe.com/connectors/adobe-commerce/payments)
yet present in the source, which maps the method and ships its icon;
methods render through Stripe's Payment Element and are switched on
from the Stripe Dashboard, so verify in a Polish test mode.
Per-country pricing is published, including a
[Czech price list](https://stripe.com/en-cz/pricing).

**Mollie** is the strongest combination of openness and Hyvä
alignment. The [module](https://github.com/mollie/magento2) is
public, vendor-maintained, and released roughly monthly. GraphQL
support sits in the source and covers the full headless placement
flow: it extends Magento's own payment mutations and hands back the
Mollie redirect URL. Mollie maintains its own
[Hyvä theme](https://github.com/mollie/magento2-hyva-compatibility)
and
[Hyvä Checkout](https://github.com/mollie/magento2-hyva-checkout)
compatibility modules, announced a
[strategic partnership](https://www.hyva.io/blog/news/hyva-commerce-mollie-partnership.html)
with Hyvä in October 2024, and contributes financially to Mage-OS on
[Open Collective](https://opencollective.com/mage-os), though it
states no technical Mage-OS support. The
[v3.0.0 release](https://github.com/mollie/magento2/releases/tag/v3.0.0)
in June 2026 was a breaking upgrade (Magento 2.4.5 and PHP 8.1
minimums, Orders API removed). Stores on older platforms stay on
the 2.x line with no stated end-of-support date. Method coverage is
Western and Central European (iDEAL, SEPA, BLIK, Przelewy24, EPS,
Twint), mostly as redirects to Mollie's hosted page. We found no
Czech or Slovak bank-button method in its list. Pricing is
[published](https://www.mollie.com/pricing) per method, per
transaction, with no minimum costs.

**PayPal and Braintree** are two different products that ship
together. The core PayPal module is part of the platform in every
distribution including Mage-OS, with its source public inside
Magento itself. Braintree is the one extension still bundled with
Magento, developed by Gene Commerce for PayPal. The currently
bundled 4.x line has no public source or issue tracker
([Gene's public repository](https://github.com/genecommerce/module-braintree-magento2)
stops at the legacy 4.0.x line), so bugs are filed against Magento
itself. The platform resolves the Braintree version through an
extensions metapackage whose loose constraint is how the downgrade
in [issue #39989](https://github.com/magento/magento2/issues/39989)
happened. Newer versions ship on Adobe's composer
repository between platform releases and can be required explicitly.
Magento 2.4.9 extended the extension with BLIK and with invoice
purchase for Germany via Ratepay
([2.4.9 release notes](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-9)),
while
[Adobe's Braintree page](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/braintree)
lists SEPA/ELV Direct Debit as not yet supported. GraphQL support
ships as the separate `paypal/module-braintree-graph-ql` package,
visible in the composer output of the same issue, and Adobe documents
the
[GraphQL flows](https://developer.adobe.com/commerce/webapi/graphql/payment-methods/braintree-vault).
PayPal publishes Braintree pricing per country: the
[German fee page](https://www.paypal.com/de/enterprise/paypal-braintree-fees)
lists 1.9% plus EUR 0.30 for cards and third-party wallets at
standard-merchant rates, the same figure as its
[Czech](https://www.paypal.com/cz/enterprise/paypal-braintree-fees)
and
[Polish](https://www.paypal.com/pl/enterprise/paypal-braintree-fees)
pages, though with no rate for the Ratepay invoice method. The
legacy Payflow methods in the core module are
[marked legacy by PayPal](https://developer.paypal.com/api/nvp-soap/)
and available only in the United States, Canada, Australia and New
Zealand per
[Adobe's Payflow Pro page](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/paypal/paypal-payflow-pro),
which also flags Payflow Pro as needing a third-party plugin for
PSD2; treat them as absent in Europe. The Hyvä Checkout integrations
for PayPal and for Braintree are both Hyvä-namespace packages.

**Klarna** sells its own methods (invoice, installments, pay now)
rather than a full acquiring stack, and in DACH that makes it hard
to avoid. Its
[purchase-country list](https://docs.klarna.com/klarna-payments/in-depth-knowledge/puchase-countries-currencies-locales/)
includes Germany, Austria, the Czech Republic, Slovakia and Poland.
The module record is mixed. Distribution is Marketplace-only with an
Apache 2.0 label but no public source or issue tracker, and the
[listing](https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
contradicts its own release notes: the description still advertises
Klarna Checkout and Magento 2.4.4 support, while the release notes
record Klarna Checkout removed in 4.0.0 and support for 2.4.4 and
2.4.5 dropped in the 4.x line. The `monolog` conflict above made the
module an upgrade blocker for six to nine weeks.
Klarna's
[own docs](https://docs.klarna.com/platform/adobe-commerce/payments/klarna-payments-module/)
state GraphQL and headless support. There is no European price
list. The Marketplace listing says additional fees apply and points
its contact link at a signup page, not at published rates. The Hyvä
Checkout integration is another hyva-themes package, and its
[tracker ticket](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/12)
labels it community-maintained. The 2026 cadence has been fast:
4.1.1 in January
([archived listing](http://web.archive.org/web/20260215102634/https://commercemarketplace.adobe.com/klarna-m2-klarna.html))
to 4.11.1 in July, on the live listing above.

**Unzer**, the former heidelpay, carries the DACH method set under a
single acquiring contract:
[its own secured invoice purchase and installments](https://docs.unzer.com/payment-methods/)
for Germany, Austria and Switzerland, plus EPS, Twint and SEPA
Direct Debit. Cards render as Unzer-hosted embedded components,
several methods as redirects. The engineering signals are weaker.
The [repository](https://github.com/unzerdev/magento2) is public
under Apache 2.0 but has issues disabled. The module contains no
GraphQL support at all (we checked the full file tree), and the
vendor's documentation contradicts itself on supported Magento
versions (2.4.5 and later on the
[installation page](https://docs.unzer.com/plugins/magento-2/magento2-install-plugin/),
2.4.6 to 2.4.8 on the
[plugin overview](https://docs.unzer.com/plugins/magento-2/)). Its
three Hyvä repositories
([magento2-hyva-checkout](https://github.com/unzerdev/magento2-hyva-checkout)
and siblings) carry no tags or releases and were last pushed in
December 2025, although the
[docs](https://docs.unzer.com/plugins/magento-2-hyva-checkout/)
state a Hyvä Checkout plugin 1.0.0 released February 2026. Unzer
[publishes entry-level rates](https://www.unzer.com/en/pricing-information/)
(from 1.50% plus EUR 0.20 per transaction, a monthly fee from EUR
19, and EUR 149 setup) and negotiates volume pricing individually.

## The local gateways: CZ, SK, PL

**GoPay**, by
[its own figures](https://www.gopay.com/cs/platebni-brana/) one of
the largest Czech and Slovak gateways, does not maintain a Magento
module itself. Its
[integration page](https://www.gopay.com/en/integration/) lists
first-party modules for Shoptet, WooCommerce, Shopify, OpenCart and
PrestaShop. For Magento, its
[help center](https://help.gopay.com/en/knowledge-base/integration-of-payment-gateway/essential-guide-to-integration)
points to five third-party suppliers. Of the supplier pages we could
reach, every module is paid and closed-source, with no public
repository and no mention of Hyvä.
[One](https://maghos.com/gopay-payment-for-magento-2.html) supports
Magento only up to 2.4.6, and another (Artio, reachable from the
supplier list above) states compatibility only with Magento 2.2.x on
PHP 7.0. The fifth supplier's store was unreachable when we checked,
and the
[last archived version](https://web.archive.org/web/20211203/https://connect20.aveo-trade.cz/details=1/extension=atconnect/magento-two-gopay)
of its module dates to February 2019.
Neither Hyvä tracker has a GoPay entry, no reachable supplier page
mentions GraphQL, and a search on the Adobe Commerce Marketplace
currently displays no GoPay extension. The gateway itself covers
what a Czech checkout needs
([bank buttons, QR payments, wallets, deferred payment](https://www.gopay.com/en/payment-methods/))
at [published pricing](https://www.gopay.com/en/pricing/), through a
redirect or an embedded overlay depending on the supplier's module.
Budget for the integration as custom work with a third-party vendor,
and review the module before it ships, starting with its webhook
handling.

**Comgate** follows the same pattern: its own docs delegate the
Magento module to
[Platiti.cz](https://help.comgate.cz/docs/open-source-reseni), the
modules on offer are paid and closed, the only public repository is
an [unofficial one](https://github.com/ppexxi/comgate_magento2)
inactive since 2021, neither Hyvä tracker has a Comgate entry, and
neither supplier page mentions GraphQL or headless support. The
gateway's standard flow, a redirect to Comgate's hosted page, keeps
the store in the smallest PCI scope. Comgate also offers embedded
modes, and at least one of the closed modules advertises them, so
confirm which flow the module you buy actually uses. The method list is broad for the region: cards,
wallets, BLIK, deferred payment via Twisto and Skip Pay, and what
[Comgate's site](https://www.comgate.eu/cs/platebni-brana) describes
as a full range of banks in the Czech Republic, Slovakia and
Poland. On transfers and QR payments, the
gateway's value over the self-generated QR code many Czech stores
already print on invoices is instant confirmation and automatic
order matching. Pricing is
[published](https://www.comgate.eu/cs/cenik-platebni-brany) down to
the chargeback fee.

**PayU** is the one CEE gateway that maintains its Magento module
the way the international vendors do:
[public repository](https://github.com/PayU-EMEA/plugin_magento_24),
Apache 2.0, vendor-maintained, Magento 2.4 only. The cadence is
uneven, with a nine-month gap between releases in 2025 and 2026,
then four releases in 2026. Hyvä Checkout support exists but is
third-party (Snowdog) and marked incomplete on the
[official tracker](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/work_items/553),
with its last tagged version (2.0.0) from April 2024. The module has
no GraphQL support. Its feature list has no BLIK-specific method, so
BLIK runs inside the generic redirect, which
[PayU's docs](https://developers.payu.com/europe/docs/payment-solutions/blik/)
describe as limited to standard pay-by-link; the in-checkout code
entry and one-click variants belong to its direct API. Card payment
is an on-site form; the remaining methods redirect. Polish pricing
is [published](https://poland.payu.com/en/pricing/).

**Przelewy24** maintains its module itself, which sets it apart from
the Czech gateways, though without a public repository the
maintenance cannot be watched. The current module for Magento 2.4.4
and later is
[distributed through the Marketplace](https://commercemarketplace.adobe.com/przelewy24-magento2-przelewy24.html)
under a GPL-3.0 label with no public repository or issue tracker and
no per-version release dates. Older builds, a separate
GraphQL/PWA/VUE variant, and the vendor's own Hyvä Checkout module
(v1.0.0, which the page dates March 24, 2026) are
[downloadable from its own site](https://www.przelewy24.pl/en/download).
We unpacked both extras. The Hyvä module carries Magewire checkout
components for BLIK, cards, Google Pay and Apple Pay on top of
`hyva-themes/magento2-hyva-checkout`. The GraphQL variant (its
composer manifest says 1.3.0; the page dates it February 9, 2026) is
a server-side GraphQL module wired into Magento's payment mutation,
with no PWA or Vue frontend code despite the label. Both extras are
absent from the Hyvä trackers, so tracker visibility and first-line
support sit with the vendor alone. Its Polish competitors TPay and
PayPo have Hyvä Checkout tracker entries
([TPay](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/549),
[PayPo](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/550)),
PayPo's module Snowdog-maintained and TPay's the vendor's own. The
default flow is a redirect, with optional in-checkout card and BLIK
entry. Its documented BLIK support is the most complete among these
modules: the redirect, in-checkout code entry, and one-click BLIK,
all per the vendor's Marketplace listing and release notes.
Standard pricing is
[published](https://www.przelewy24.pl/bramka-platnicza).

## Side by side

| Gateway | Module maintainer | Public source | Hyvä Checkout | GraphQL | Public pricing |
| ------- | ----------------- | ------------- | ------------- | ------- | -------------- |
| Adyen | Vendor | Yes | Hyvä namespace | Documented | Yes |
| Stripe | Vendor | Archives only | Hyvä namespace | In source | Yes |
| Mollie | Vendor | Yes | Vendor | In source | Yes |
| Braintree (bundled) | Gene for PayPal | No | Hyvä namespace | Platform package | Yes |
| Klarna | Vendor | No | Hyvä namespace | Documented | No |
| Unzer | Vendor | Yes | Vendor, unversioned | No | Entry rates |
| GoPay | Third parties | No | None found | None stated | Yes |
| Comgate | Third parties | No | None found | None stated | Yes |
| PayU | Vendor | Yes | Third party, partial | No | Yes |
| Przelewy24 | Vendor | No repository | Vendor, untracked | Separate build | Yes |

"Hyvä namespace" means the integration package is published under
`hyva-themes`, with first-line responsibility per the checkout
tracker's Vendor and Community labels. In the GraphQL column,
"Documented" means the vendor states support and we did not read the
code; "In source" means we read it in public code; "Platform
package" means it ships as a separate composer package alongside the
platform, with the flows documented by Adobe. Przelewy24's GraphQL
support ships as a separate downloadable module; we unpacked it and
found a server-side GraphQL API with no frontend code despite its
PWA label. The Braintree row covers the bundled extension; the core
PayPal module's source is public inside Magento itself. Cells
follow from the sources linked above; "None stated" and "None
found" record our own searches. All as of August 2, 2026.

## Start from the market, then disqualify

In Germany, the EHI Retail Institute's payment study puts PayPal
at 28.5 percent of online retail revenue in 2024, invoice purchase
at 25.8 percent, direct debit at 17.3 percent and cards at 12.3
percent
([EHI](https://www.ehi.org/presse/paypal-festigt-spitzenposition/)).
A German checkout therefore needs PayPal, an invoice product and
SEPA Direct Debit before it needs anything else. Braintree covers
PayPal and, on Magento 2.4.9, invoice purchase via Ratepay. Klarna
and Unzer both sell the invoice product. For direct debit the
options here are Unzer, Mollie, Adyen or Stripe, since Adobe's
Braintree documentation lists SEPA Direct Debit as not yet
supported. The Ratepay route requires Magento 2.4.9, which Adyen's
plugin has supported since v10.10.0; the pairing therefore works on
a current platform, and on 2.4.8 and below the invoice options are
Klarna and Unzer. None of the three carriers publishes a rate for
the invoice product itself: Braintree's German fee page prices
cards and wallets with no Ratepay row, Klarna publishes no list at
all, and Unzer's entry rates are generic "from" figures. For the
market's second-largest method, the fee comparison runs on quotes.
Cards carried about an eighth of that revenue. A cards-only
checkout therefore gives up conversion against competitors that
offer the preferred methods, even where buyers could pay by card.

In Poland, BLIK's operator commissioned an EY report that puts BLIK
at about half of Polish online sales value in 2023, measured across
BLIK, cards and transfers
([EY report for BLIK](https://www.blik.com/media/2025_03_12_EY_BLIK_payments_and_economy_report.pdf);
the figure is the operator's own, built on central bank data). A
Polish checkout without BLIK gives up the market's leading online
payment method. PayU, Przelewy24 and Comgate carry it natively.
Among the internationals, Adyen and Mollie list BLIK, Braintree
added it in Magento 2.4.9, and Stripe's module documentation omits
it. Most of the field carries BLIK in some form. What separates the
options in Poland is BLIK depth (redirect, in-checkout entry, or
one-click) and module quality. Przelewy24 documents the most
complete implementation, with the caveat from its profile: its Hyvä
Checkout module ships from its own site and appears in neither Hyvä
tracker, so first-line support sits with the vendor alone.

In the Czech Republic, the 2024 wave of APEK's consumer survey, as
published in Shoptet's Stav české e-commerce, has cards as the
method shoppers use most, at 42 percent, with Google and Apple Pay
at 23, cash on delivery at 13 and bank transfer at 12
([live page](https://www.ceska-ecommerce.cz/),
[archived](http://web.archive.org/web/20250401235543/https://www.ceska-ecommerce.cz/)
since the live page is overwritten annually; the shares match
[APEK's own 2024 series](https://data.apek.cz/)). Any international
gateway covers the cards and wallets. The bank buttons and QR
payments behind part of that transfer share are carried by GoPay
and Comgate, whose Magento
modules are the weakest of the ten. So the Czech question is whether
the transfer and cash-on-delivery share justifies a second gateway
at all: an international provider for cards plus a local gateway for
transfers costs a second module on every upgrade, a second
reconciliation and fee schedule, and per-method deduplication in
checkout, since both sides offer cards and wallets. The pairing
makes sense only if the card-fee savings exceed that overhead.
(The Czech and Slovak acquirer-side gateways, GP webpay, ČSOB,
TrustPay, are outside this comparison; the bank-button coverage runs
through GoPay and Comgate.) In Slovakia, cash on delivery is still
at 25 to 30 percent of orders per an analysis by Upgates, an
e-commerce platform operator, reported by the TASR press agency in
[June 2026](https://www.teraz.sk/ekonomika/dobierky-predstavuju-pre-e-shopy-najna/973629-clanok.html).
That is mostly a fulfillment decision, but it still
touches the payment setup through carrier reconciliation and the
offline payment method, and the deferred-payment products above are
the gateways' answer to it. Slovakia settles in euro, which removes
the currency argument for a local gateway there.

So the procedure is: list the methods your market requires, keep the
gateways, or minimal combinations of them, that jointly carry those
methods, disqualify on the module and operational criteria above,
and only then compare fees, settlement currency included, among the
survivors.

If you are choosing a gateway as part of a broader build, or
inheriting one that blocks an upgrade, that assessment is part of
our [Magento work](/services/magento/), and connecting a gateway to
an ERP or subscription flow is what our
[integrations service](/services/integrations/) covers.