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 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 for the theme and a separate integration tracker for Hyvä Checkout, and its documentation lists the primary tracked payment integrations. 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 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 (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 (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 for EU merchants including CZK and PLN, Mollie lists 13 payout currencies, PayU settles 1:1 in 11, and GoPay documents payout currencies per bank. Comgate publishes per-currency payout terms, and Braintree publishes its scheme-currency list, with each merchant’s set agreed at onboarding and extended by requesting additional merchant accounts. Klarna pays out in the transaction currency. 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). 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 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 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 and first show the fixed line on June 13, 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 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 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ä 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, 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 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). 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). 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 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 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 (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, and the EU method coverage includes iDEAL, SEPA Direct Debit, BLIK, Twint and Bancontact, with cards rendered as embedded components inside the checkout. Pricing is published as interchange++ 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 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), 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. 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 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 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.

Mollie is the strongest combination of openness and Hyvä alignment. The module 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 and Hyvä Checkout compatibility modules, announced a strategic partnership with Hyvä in October 2024, and contributes financially to Mage-OS on Open Collective, though it states no technical Mage-OS support. The v3.0.0 release 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 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 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 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), while Adobe’s Braintree page 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. PayPal publishes Braintree pricing per country: the German fee page lists 1.9% plus EUR 0.30 for cards and third-party wallets at standard-merchant rates, the same figure as its Czech and Polish pages, though with no rate for the Ratepay invoice method. The legacy Payflow methods in the core module are marked legacy by PayPal and available only in the United States, Canada, Australia and New Zealand per Adobe’s Payflow Pro page, 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 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 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 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 labels it community-maintained. The 2026 cadence has been fast: 4.1.1 in January (archived listing) 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 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 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, 2.4.6 to 2.4.8 on the plugin overview). Its three Hyvä repositories (magento2-hyva-checkout and siblings) carry no tags or releases and were last pushed in December 2025, although the docs state a Hyvä Checkout plugin 1.0.0 released February 2026. Unzer publishes entry-level rates (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 one of the largest Czech and Slovak gateways, does not maintain a Magento module itself. Its integration page lists first-party modules for Shoptet, WooCommerce, Shopify, OpenCart and PrestaShop. For Magento, its help center 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 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 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) at published 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, the modules on offer are paid and closed, the only public repository is an unofficial one 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 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 down to the chargeback fee.

PayU is the one CEE gateway that maintains its Magento module the way the international vendors do: public repository, 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, 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 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.

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 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. 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, PayPo), 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.

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). 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; 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, archived since the live page is overwritten annually; the shares match APEK’s own 2024 series). 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. 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, and connecting a gateway to an ERP or subscription flow is what our integrations service covers.