---
title: "Zahlungsanbieter für Magento 2 auswählen"
description: "Ein Entscheidungsrahmen für Zahlungsanbieter auf Magento 2, Adobe Commerce und Mage-OS: Modulpflege, Verhalten bei Upgrades, Hyvä- und Headless-Unterstützung und die lokalen Zahlungsmethoden, die in jedem Markt die Auswahl bestimmen."
author: "Luboš Zápotočný"
published: "2026-08-02"
language: "de"
canonical: "https://zapolu.com/de/blog/zahlungsanbieter-fuer-magento/"
---

# Zahlungsanbieter für Magento 2 auswählen

Die Wahl eines Zahlungsanbieters für einen Magento-Shop wird meist als
Gebührenvergleich verstanden. Bei Magento spielen die Gebühren jedoch
eine untergeordnete Rolle, denn fast jede Anbieterentscheidung bringt
eine zweite mit sich: welches Magento-Modul Sie betreiben. Das Modul
liegt in Ihrer Codebasis und rendert im Checkout, und ein
Plattform-Upgrade nimmt es entweder mit oder scheitert daran. Ein
Zahlungsmodul ist der Drittanbietercode, der bei jeder Bestellung am
unmittelbarsten mit dem Zahlungsfluss verbunden ist.

Dieser Beitrag liefert eine Checkliste für die Wahl eines Gateways und
wendet sie anschließend auf sechs internationale Anbieter (Adyen,
Stripe, Mollie, PayPal mit Braintree, Klarna, Unzer) sowie vier
Gateways für den tschechischen, slowakischen und polnischen Markt an
(GoPay, Comgate, PayU, Przelewy24). Jede Angabe zu den Anbietern wurde
am 2. August 2026 anhand der verlinkten Quelle geprüft; wo sich etwas
nicht verifizieren ließ, ist das vermerkt.

## Was vor der Unterschrift zu prüfen ist

**Wer pflegt das Modul, und lässt sich der Code lesen?** Adyen,
Mollie, Unzer und PayU pflegen ihre Magento-Module in öffentlichen
Repositories. Stripe veröffentlicht nur Release-Archive, der
Issue-Tracker ist deaktiviert. Klarna und Przelewy24 veröffentlichen
trotz Open-Source-Lizenzhinweis auf ihren Paketen überhaupt kein
Quellcode-Repository. GoPay und Comgate haben kein eigenes Modul. Die
angebotenen Module sind kostenpflichtig und geschlossen und stammen
von Drittanbietern. Auch die aktuelle Linie der mitgelieferten
Braintree-Erweiterung hat keinen öffentlichen Quellcode; Genes
Repository endet bei dessen alten 4.0.x-Releases. Ein öffentliches
Repository ist keine Qualitätsgarantie, erlaubt es aber, den Diff vor
einem Upgrade zu lesen, statt sich auf das Changelog zu verlassen.

**Wie es sich bei Plattform-Upgrades verhalten hat.** Der nächste
Abschnitt beschreibt die drei Fehlermuster, nach denen es sich zu
suchen lohnt. Wo der Anbieter keinen öffentlichen Tracker führt, und
das trifft auf sieben der zehn hier genannten zu, suchen Sie im
Magento-eigenen Tracker nach dem Modulnamen: Beide unten
beschriebenen Vorfälle wurden dort erfasst, nicht im Tracker eines
Anbieters.

**Die operativen Abläufe hinter dem Checkout.** Ein Redirect-Modul
hängt von seiner asynchronen Bestätigung ab: dem Webhook-Endpunkt,
dessen Signaturprüfungen und Wiederholungsversuchen, sowie davon, was
mit einer Bestellung geschieht, deren Kunde nie von der
Zahlungsseite zurückkehrt. Rückerstattungen sind der nächste
Prüfpunkt. Manche Module stellen sie aus einer Magento-Gutschrift
aus, andere nur im Backoffice des Zahlungsanbieters, und dieselbe
Trennung zieht sich durch die Erfassung bei Versand sowie durch im
Admin angelegte Bestellungen. Zahlungstoken sind gesondert zu
klären, denn Magento-seitige Abo-Erweiterungen erwarten
[Vault](https://developer.adobe.com/commerce/php/development/payments-integrations/vault/),
während die unten genannten lokalen Gateways in der Regel ihre
eigenen serverseitig tokenisierten wiederkehrenden Zahlungen
dokumentieren. Klären Sie, welche der beiden Varianten das Modul
bereitstellt. In Tschechien, der Slowakei und Polen kann eine vor
dem Versand erfasste Zahlung eine umsatzsteuerliche
Anzahlungsrechnungspflicht auslösen, ein Grund, warum Händler dort
die Erfassung bei Versand konfigurieren. Klären Sie den Ablauf mit
Ihrem Steuerberater. Die Profile unten enthalten diese Angaben
nicht. Die meisten Anbieter veröffentlichen sie nur in der
Moduldokumentation, die geschlossenen Module gar nicht. Führen Sie
diese Prüfung bei den Modulen durch, die es auf Ihre Shortlist
schaffen.

**Hyvä-Unterstützung, wie sie die öffentlichen Tracker
dokumentieren.** Hyvä pflegt einen öffentlichen
[Kompatibilitäts-Tracker für Module](https://gitlab.hyva.io/hyva-public/module-tracker)
für das Theme sowie einen eigenen
[Integrations-Tracker](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker)
für Hyvä Checkout, und die Dokumentation
[listet die wichtigsten erfassten Zahlungsintegrationen auf](https://docs.hyva.io/hyva-checkout/integrations/available-payment-methods.html).
Jedes Ticket im Checkout-Integrations-Tracker trägt das Label
„Vendor“ oder „Community“ und zeigt so, wer für die Umsetzung und
den First-Level-Support verantwortlich ist. Wer das ist, zählt
ebenso wie die Frage, ob die Integration überhaupt existiert, denn
davon hängt ab, wer sie korrigiert, wenn das Gateway ein
inkompatibles Release ausliefert.

**Headless-Abdeckung.** Magentos
[`setPaymentMethodOnCart`-Mutation](https://developer.adobe.com/commerce/webapi/graphql/schema/cart/mutations/set-payment-method)
überträgt einen Methodencode plus ein methodenspezifisches
Eingabeobjekt, das die Referenzdokumentation für jede
Online-Zahlungsmethode voraussetzt. Ein Modul ohne eigene
GraphQL-Schicht kann weder tokenisierte Zahlungsdaten empfangen noch
Redirect-Handling über GraphQL zurückgeben. Ein Headless-Build
gleicht die Lücke dann durch Individualentwicklung aus, meist über
REST.

**PCI-DSS-Geltungsbereich.** Nach dem
[SAQ-Leitfaden](https://listings.pcisecuritystandards.org/documents/Understanding_SAQs_PCI_DSS_v3.pdf)
des PCI Security Standards Council (eine Erläuterung aus der
v3-Ära; die aktuellen v4-Fragebögen behalten die Unterscheidung
zwischen Redirect und iFrame bei) kann ein vollständiger Redirect
oder ein vom Anbieter gehosteter iFrame den Händler auf SAQ A, dem
kurzen Fragebogen, halten; Zahlungsformulare oder Zahlungs-JavaScript,
die von der eigenen Seite ausgeliefert werden, bedeuten SAQ A-EP.
Nach den Zulassungskriterien der Version 4.0.1, erläutert 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/)
(Februar 2025), verlangt selbst eine iFrame-Integration, dass die
Händlerseite gegen Skriptangriffe geschützt ist, oder die
Bestätigung des Anbieters, dass seine Lösung dies gewährleistet; ein
reiner Redirect bleibt der kleinste Geltungsbereich.

**Die Zahlungsmethoden, die Ihr Markt tatsächlich nutzt.** Jedes hier
genannte Gateway verarbeitet Kartenzahlungen. Entscheidend sind der
Rechnungskauf in Deutschland, die BLIK-Tiefe in Polen und in
Tschechien die Frage, ob der Anteil von Überweisung und Nachnahme ein
lokales Gateway überhaupt rechtfertigt. Der Marktabschnitt unten
liefert die Zahlen und ihre Quellen.

**Veröffentlichte Preise, in den Währungen, in denen Sie
abrechnen.** Adyen, Stripe, Mollie, PayPal, GoPay, Comgate, PayU und
Przelewy24 veröffentlichen Preislisten. Unzer veröffentlicht
Einstiegstarife und verhandelt Volumenpreise individuell. Klarna
veröffentlicht keine europäische Preisliste, und die Gesamtkosten
lassen sich aus öffentlichen Angaben nicht berechnen. Prüfen Sie
außerdem, ob das Gateway in jeder Währung abrechnet, in der Sie
verkaufen, oder zu einem eigenen Kurs umrechnet; die Umrechnung
steht außerhalb der ausgewiesenen Gebühr. Vieles davon ist öffentlich:
[Adyen listet für EU-Händler 26 Abrechnungswährungen](https://docs.adyen.com/account/supported-currencies)
auf, darunter CZK und PLN,
[Mollie listet 13 Auszahlungswährungen](https://help.mollie.com/hc/en-us/articles/5546871220370-What-are-multi-currency-payouts),
[PayU rechnet in 11 Währungen 1:1 ab](https://developers.payu.com/europe/docs/get-started/integration-overview/references/),
und
[GoPay dokumentiert Auszahlungswährungen je 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 veröffentlicht die Auszahlungsbedingungen je Währung](https://help.comgate.cz/docs/vyplaceni-penez-na-ucet),
und
[Braintree veröffentlicht seine Liste der Schema-Währungen](https://developer.paypal.com/braintree/docs/reference/general/currencies),
wobei die je Händler geltende Auswahl beim Onboarding vereinbart und
durch
[Anfrage weiterer Händlerkonten](https://developer.paypal.com/braintree/articles/get-started/currencies)
erweitert wird.
[Klarna zahlt in der Transaktionswährung aus](https://docs.klarna.com/acquirer/klarna/web-payments/additional-resources/use-cases/consumer-fx/).
Die übrigen veröffentlichen weniger: Stripe rendert seine
Abrechnungstabelle clientseitig, Przelewy24 gibt Auszahlungen in PLN
oder EUR an, und Unzer veröffentlicht keine Liste.

## Was Upgrades mit Zahlungsmodulen anstellen

Drei Fehlermuster sind in öffentlichen Trackern und Release Notes
dokumentiert, und alle drei lohnt es, bei jedem Modul auf Ihrer
Shortlist zu prüfen.

Das erste ist die Entbündelung. Die Release Notes zu Magento 2.4.4
halten fest: „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)).
Seither versionieren Zahlungsmodule unabhängig von der Plattform, und
ein Core-Upgrade impliziert kein kompatibles Zahlungsmodul mehr.

Das zweite ist das Auseinanderlaufen von Abhängigkeiten.
[Issue #39989](https://github.com/magento/magento2/issues/39989)
gegen Magento dokumentiert, wie der Sicherheitspatch 2.4.8-p1 auf
betroffenen Installationen sechs `paypal/module-braintree`-Pakete von
4.7.0 auf 4.6.1-p5 zurückstuft, über eine Metapaket-Beschränkung, die
Composer freistellte, welche der beiden Versionen es wählt.
Umgekehrt dokumentiert
[Issue #39803](https://github.com/magento/magento2/issues/39803),
wie das Klarna-Modul das Upgrade auf 2.4.8 durch einen
Versionskonflikt mit `monolog` rundheraus blockierte. Adobe schloss
das Issue nach elf Tagen mit dem Hinweis an die Shops, Klarna sei als
Erweiterungshersteller zuständig. Der Fix erschien mit
Modul-Release 3.3.1: Archivierte Aufnahmen des Marketplace-Eintrags
zeigen am
[20. Mai 2025](http://web.archive.org/web/20250520080628/https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
noch die unkorrigierte Version 3.3.0, und erst am
[13. Juni](http://web.archive.org/web/20250613064417/https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
die korrigierte Linie. Shops mit dem Modul waren also sechs bis neun
Wochen nach der Verfügbarkeit vom 8. April blockiert.

Das dritte ist Frontend-Kopplung. Die
[Release Notes zu Mage-OS 2.2.1](https://mage-os.org/releases/2026-03-18-mage-os-2-2-1-release/)
machen eine Optimierung des verzögerten reCAPTCHA-Ladens aus 2.2.0
rückgängig, weil sie auf Checkout-Seiten mit gehosteten und
iFrame-Zahlungsformularen zu reCAPTCHA-Fehlern führte.
Zahlungsmodule hängen von der Ladereihenfolge im Checkout und vom
Skript-Timing ab, sodass eine unabhängige Frontend-Änderung den
Zahlungsschritt im Checkout stören kann. Dieselbe Kopplung macht die
Hyvä-Kompatibilität zu einer eigenständigen Aufgabe.

Speziell zu Mage-OS: Die Distribution liefert das PayPal-Kernmodul,
aber nicht Braintree (geprüft anhand des Metapakets
`mage-os/product-community-edition`), und keiner der zehn Anbieter
unten nennt an irgendeiner Stelle, die wir finden konnten,
Mage-OS-Unterstützung. Mage-OS selbst
[erklärt volle Kompatibilität](https://mage-os.org/faq/) mit
Open-Source-Erweiterungen von Magento, sodass ein Modul, das auf
Open Source läuft, auch dort funktionieren sollte. Diese Erwartung
beruht allein auf der Aussage von Mage-OS; kein Zahlungsanbieter
sichert sie zu. Das gilt für alle zehn Gateways
gleichermaßen und ist eine Frage der Plattformentscheidung, nicht
der Gateway-Wahl.

## Hyvä verändert die Shortlist

Ein [Hyvä](/de/blog/hyva-vs-luma/)-Storefront verändert die
Zahlungsfrage in einer Hinsicht. Mit dem Hyvä-Theme allein kann der
Checkout über den dokumentierten
[Theme-Fallback](https://docs.hyva.io/hyva-themes/building-your-theme/luma-theme-fallback.html)
auf dem regulären Luma-Checkout bleiben, wo bestehende
Zahlungsmodule weiterlaufen. Der Fallback wird pro Route
konfiguriert und bedeutet, dass neben Hyvä ein Luma-basiertes
Checkout-Theme mitgepflegt werden muss. Und weil er nur für die
konfigurierten Routen gilt, bleiben die
Express-Zahlungsschaltflächen (Apple Pay, Google Pay, PayPal), die
Module auf Produkt-, Warenkorb- und Mini-Warenkorbseiten rendern, im
Hyvä-Theme und benötigen weiterhin Hyvä-Kompatibilität vom Modul.
[Hyvä Checkout](https://docs.hyva.io/hyva-checkout/devdocs/payments/payment-in-hyva-checkout.html)
ist anders gelagert: Die Bestellauslösung wandert von der
Zahlungsmethode zu einem zentralen Service, sodass das
Luma-Frontend eines Zahlungsmoduls dort nicht läuft. Laut
Hyvä-Dokumentation lässt sich das Backend des Moduls meist
weiterverwenden, während die checkout-seitige Schicht neu gebaut
werden muss. Jeder Anbieter braucht eine eigene Integration. Solange
niemand eine baut, ist der dokumentierte Weg um eine fehlende
Integration herum der Luma-Fallback.

Die Pflegevereinbarungen hinter diesen Integrationen sind nicht
einheitlich, und Adyen zeigt, warum das zählt. Adyen schrieb sein
eigenes Hyvä-Checkout-Modul und beendete dann dessen Pflege. Die
README beginnt inzwischen mit dem Hinweis, dass die Integration
nicht mehr offiziell unterstützt wird und keine neuen Updates mehr
erhält
([adyen-magento2-hyva](https://github.com/adyen-examples/adyen-magento2-hyva)).
Das Hyvä-Team übernahm die Integration und veröffentlichte im März
2026 ein neu geschriebenes Paket,
`hyva-themes/magento2-hyva-checkout-adyen-payment-v2`, für Adyens
v10-Plugin
([Handover-Issue](https://github.com/adyen-examples/adyen-magento2-hyva/issues/140)).
Händler, die sich unter anderem wegen der nativen Hyvä-Unterstützung
für Adyen entschieden haben, sind nun auf das von Hyvä gepflegte
Paket angewiesen, und auf eine Plugin-Hauptversion, die Magento
2.4.8 oder neuer voraussetzt.

## Die sechs internationalen Anbieter

**Adyen** pflegt
[sein Magento-Plugin](https://github.com/Adyen/adyen-magento2)
öffentlich unter MIT-Lizenz und hat es in den vergangenen zwölf
Monaten, gezählt anhand der Releases-Seite des Repositorys, vierzig
Mal über die parallelen Linien v9 und v10 veröffentlicht. Der Preis
für dieses Tempo ist ein strikter Support-Zeitplan:
[Adyens eigene Tabelle](https://docs.adyen.com/plugins/adobe-commerce)
gibt jeder Plugin-Hauptversion ein festes Zeitfenster (zwei Jahre
für v10), und Shops auf 2.4.4 bis 2.4.7 bleiben auf der v9-Linie, seit
Mai 2026 im Modus „nur Sicherheitsupdates“ und mit Ende im Dezember
2026. Die v10-Linie brachte mit
[v10.10.0](https://github.com/Adyen/adyen-magento2/releases/tag/v10.10.0)
(31. März 2026) Unterstützung für Magento 2.4.9 und PHP 8.5, auch
wenn Support-Tabelle und README zum Zeitpunkt unserer Prüfung noch
nur 2.4.8 nannten; maßgeblich sind die Release Notes. Headless wird
über dokumentierte
[GraphQL-Unterstützung](https://docs.adyen.com/plugins/adobe-commerce/headless-integration/)
abgedeckt, und die EU-Methodenabdeckung
[umfasst iDEAL, SEPA-Lastschrift, BLIK, Twint und Bancontact](https://docs.adyen.com/plugins/adobe-commerce/supported-payment-methods/),
wobei Karten als eingebettete Komponenten im Checkout dargestellt
werden. Die Preise sind
[als Interchange++](https://www.adyen.com/pricing) mit
methodenspezifischen Gebühren veröffentlicht. Planen Sie alle ein
bis zwei Jahre eine Plugin-Migration ein; genau das empfiehlt Adyens
README.

**Stripe** liefert ein leistungsfähiges Modul, entwickelt in einem
geschlossenen Prozess. Das
[offizielle Modul](https://github.com/stripe/stripe-magento2-releases)
wird als Release-Archiv unter Stripes eigener proprietärer Lizenz
vertrieben, mit deaktivierten GitHub-Issues: Es gibt keinen
öffentlichen Bugtracker, den man vor einem Upgrade konsultieren
könnte. Releases erscheinen etwa monatlich, der Support deckt
Magento 2.3.7 bis 2.4.x ab, mit Fixes erst ab Modul 4.5.x
([Lifecycle-Tabelle](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/install)),
und beide Checkout-Abläufe, eingebettetes Payment Element und
Redirect, sind in Stripes Dokumentation als SAQ-A-fähig
dokumentiert; die Dokumentation deckt außerdem
[REST und GraphQL für Custom Storefronts](https://docs.stripe.com/use-stripe-apps/adobe-commerce/payments/custom-storefront)
ab. Wir haben das Release-Archiv von 4.6.4 entpackt: Das
GraphQL-Schema samt Resolvern liegt im Quellcode, und composer.json
verlangt lediglich PHP 7.4 oder neuer. Lesen Sie vor jedem Upgrade
das
[Changelog](https://github.com/stripe/stripe-magento2-releases/blob/master/CHANGELOG.md):
Version 4.6.0 brachte inkompatible Änderungen für Headless-Builds,
und die
Notizen zu 4.6.2 halten fest, dass die in 4.6 eingeführten
strengeren Authentifizierungsanforderungen „decreased checkout
conversions“ verursacht hätten, bevor sie gelockert wurden. Die
Hyvä-Checkout-Integration ist unter Hyväs eigenem Namespace
veröffentlicht. Stripes Changelog erwähnt Hyvä ein einziges Mal.
Zu den EU-Methoden zählen SEPA-Lastschrift, iDEAL, Przelewy24 und
Klarna. BLIK fehlt in
[der dokumentierten Methodenliste des Moduls](https://docs.stripe.com/connectors/adobe-commerce/payments),
ist aber im Quellcode vorhanden, der die Methode zuordnet und ihr
Icon ausliefert; die Methoden werden über Stripes Payment Element
gerendert und im Stripe Dashboard aktiviert, prüfen Sie das also in
einem polnischen Testmodus. Länderspezifische Preise sind
veröffentlicht, darunter eine
[tschechische Preisliste](https://stripe.com/en-cz/pricing).

**Mollie** ist die stärkste Kombination aus Offenheit und
Hyvä-Ausrichtung. Das [Modul](https://github.com/mollie/magento2)
ist öffentlich, wird vom Anbieter gepflegt und etwa monatlich
veröffentlicht. GraphQL-Unterstützung liegt im Quellcode und deckt
den vollständigen Headless-Bestellablauf ab: Sie erweitert Magentos
eigene Payment-Mutations und gibt die Mollie-Redirect-URL zurück.
Mollie pflegt eigene Kompatibilitätsmodule für
[Hyvä-Theme](https://github.com/mollie/magento2-hyva-compatibility)
und
[Hyvä Checkout](https://github.com/mollie/magento2-hyva-checkout),
kündigte im Oktober 2024 eine
[strategische Partnerschaft](https://www.hyva.io/blog/news/hyva-commerce-mollie-partnership.html)
mit Hyvä an und trägt über
[Open Collective](https://opencollective.com/mage-os) finanziell zu
Mage-OS bei, nennt dabei aber keine technische Mage-OS-Unterstützung.
Das
[Release v3.0.0](https://github.com/mollie/magento2/releases/tag/v3.0.0)
im Juni 2026 war ein grundlegend inkompatibles Upgrade (mindestens
Magento 2.4.5 und
PHP 8.1, Orders API entfernt). Shops auf älteren Plattformen bleiben
auf der 2.x-Linie, ohne dass ein Support-Enddatum genannt wird. Die
Methodenabdeckung ist west- und mitteleuropäisch (iDEAL, SEPA,
BLIK, Przelewy24, EPS, Twint), größtenteils als Redirect auf
Mollies gehostete Seite. Eine tschechische oder slowakische
Bank-Button-Methode fanden wir in der Liste nicht. Die Preise sind
[veröffentlicht](https://www.mollie.com/pricing), je Methode und
Transaktion, ohne Mindestkosten.

**PayPal und Braintree** sind zwei verschiedene Produkte, die
zusammen ausgeliefert werden. Das PayPal-Kernmodul ist Teil der
Plattform in jeder Distribution einschließlich Mage-OS, sein
Quellcode liegt öffentlich in Magento selbst. Braintree ist die
einzige Erweiterung, die weiterhin mit Magento gebündelt wird,
entwickelt von Gene Commerce für PayPal. Die aktuell gebündelte
4.x-Linie hat keinen öffentlichen Quellcode und keinen Issue-Tracker
([Genes öffentliches Repository](https://github.com/genecommerce/module-braintree-magento2)
endet bei der alten 4.0.x-Linie), sodass Fehler gegen Magento selbst
gemeldet werden. Die Plattform löst die Braintree-Version über ein
Extensions-Metapaket auf, dessen lose Beschränkung das Downgrade in
[Issue #39989](https://github.com/magento/magento2/issues/39989)
verursacht hat. Neuere Versionen erscheinen zwischen den
Plattform-Releases in Adobes Composer-Repository und lassen sich
explizit anfordern. Magento 2.4.9 erweiterte die Erweiterung um
BLIK sowie um den Rechnungskauf für Deutschland über Ratepay
([Release Notes zu 2.4.9](https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-9)),
während
[Adobes Braintree-Seite](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/braintree)
SEPA-/ELV-Lastschrift als noch nicht unterstützt führt.
GraphQL-Unterstützung erscheint als eigenes Paket
`paypal/module-braintree-graph-ql`, sichtbar in der
Composer-Ausgabe desselben Issues, und Adobe dokumentiert die
[GraphQL-Abläufe](https://developer.adobe.com/commerce/webapi/graphql/payment-methods/braintree-vault).
PayPal veröffentlicht die Braintree-Preise je Land: Die
[deutsche Gebührenseite](https://www.paypal.com/de/enterprise/paypal-braintree-fees)
nennt 1,9 % plus 0,30 EUR für Karten und Wallets von Drittanbietern
zu Standard-Händlertarifen, denselben Wert wie die
[tschechische](https://www.paypal.com/cz/enterprise/paypal-braintree-fees)
und die
[polnische](https://www.paypal.com/pl/enterprise/paypal-braintree-fees)
Seite, allerdings ohne Tarif für die Ratepay-Rechnungsmethode. Die
Legacy-Payflow-Methoden im Kernmodul sind
[von PayPal als Legacy markiert](https://developer.paypal.com/api/nvp-soap/)
und laut
[Adobes Payflow-Pro-Seite](https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/payments/paypal/paypal-payflow-pro)
nur in den USA, Kanada, Australien und Neuseeland verfügbar; dieselbe
Seite verlangt für Payflow Pro zusätzlich ein Drittanbieter-Plugin
für PSD2, betrachten Sie sie in Europa also als nicht verfügbar. Die
Hyvä-Checkout-Integrationen für PayPal und für Braintree sind beide
Pakete im Hyvä-Namespace.

**Klarna** verkauft eigene Zahlungsmethoden (Rechnung, Ratenkauf,
Sofortzahlung) statt eines vollständigen Acquiring-Stacks, und im
DACH-Raum lässt sich das kaum umgehen. Die
[Liste der Einkaufsländer](https://docs.klarna.com/klarna-payments/in-depth-knowledge/puchase-countries-currencies-locales/)
umfasst Deutschland, Österreich, Tschechien, die Slowakei und Polen.
Die Bilanz des Moduls ist gemischt. Der Vertrieb läuft
ausschließlich über
den Marketplace mit Apache-2.0-Label, aber ohne öffentlichen
Quellcode oder Issue-Tracker, und der
[Eintrag](https://commercemarketplace.adobe.com/klarna-m2-klarna.html)
widerspricht seinen eigenen Release Notes: Die Beschreibung wirbt
weiterhin mit Klarna Checkout und Unterstützung für Magento 2.4.4,
während die Release Notes festhalten, dass Klarna Checkout in 4.0.0
entfernt und die Unterstützung für 2.4.4 und 2.4.5 in der
4.x-Linie eingestellt wurde. Der oben genannte
`monolog`-Konflikt machte das Modul für sechs bis neun Wochen zum
Upgrade-Blocker. Klarnas
[eigene Dokumentation](https://docs.klarna.com/platform/adobe-commerce/payments/klarna-payments-module/)
nennt GraphQL- und Headless-Unterstützung. Es gibt keine
europäische Preisliste. Der Marketplace-Eintrag erwähnt zusätzliche
Gebühren und verweist über den Kontaktlink auf eine
Registrierungsseite, nicht auf veröffentlichte Tarife. Die
Hyvä-Checkout-Integration ist ein weiteres Paket im
hyva-themes-Namespace, und das zugehörige
[Tracker-Ticket](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/12)
kennzeichnet sie als community-gepflegt. Die Release-Frequenz war
2026 hoch: von 4.1.1 im Januar
([archivierter Eintrag](http://web.archive.org/web/20260215102634/https://commercemarketplace.adobe.com/klarna-m2-klarna.html))
bis 4.11.1 im Juli, laut dem oben verlinkten Live-Eintrag.

**Unzer**, das frühere heidelpay, deckt den DACH-Methodensatz unter
einem einzigen Acquiring-Vertrag ab:
[eigenen abgesicherten Rechnungskauf und Ratenkauf](https://docs.unzer.com/payment-methods/)
für Deutschland, Österreich und die Schweiz, dazu EPS, Twint und
SEPA-Lastschrift. Karten werden als von Unzer gehostete eingebettete
Komponenten dargestellt, mehrere Methoden als Redirect. In
technischer Hinsicht schneidet das Modul schwächer ab. Das
[Repository](https://github.com/unzerdev/magento2) ist öffentlich
unter Apache 2.0, hat aber deaktivierte Issues. Das Modul enthält
überhaupt keine GraphQL-Unterstützung (wir haben den vollständigen
Dateibaum geprüft), und die Dokumentation des Anbieters widerspricht
sich bei den unterstützten Magento-Versionen (2.4.5 und höher auf
der
[Installationsseite](https://docs.unzer.com/plugins/magento-2/magento2-install-plugin/),
2.4.6 bis 2.4.8 in der
[Plugin-Übersicht](https://docs.unzer.com/plugins/magento-2/)). Die
drei Hyvä-Repositories
([magento2-hyva-checkout](https://github.com/unzerdev/magento2-hyva-checkout)
und verwandte) tragen keine Tags oder Releases und wurden zuletzt
im Dezember 2025 aktualisiert, obwohl die
[Dokumentation](https://docs.unzer.com/plugins/magento-2-hyva-checkout/)
ein Hyvä-Checkout-Plugin 1.0.0 mit Release im Februar 2026 angibt.
Unzer
[veröffentlicht Einstiegstarife](https://www.unzer.com/en/pricing-information/)
(ab 1,50 % plus 0,20 EUR je Transaktion, eine monatliche Gebühr ab
19 EUR und 149 EUR Einrichtung) und verhandelt Volumenpreise
individuell.

## Die lokalen Gateways: CZ, SK, PL

**GoPay**, nach
[eigenen Angaben](https://www.gopay.com/cs/platebni-brana/) eines
der größten tschechischen und slowakischen Gateways, pflegt selbst
kein Magento-Modul. Die
[Integrationsseite](https://www.gopay.com/en/integration/) listet
Erstanbieter-Module für Shoptet, WooCommerce, Shopify, OpenCart und
PrestaShop. Für Magento verweist das
[Help Center](https://help.gopay.com/en/knowledge-base/integration-of-payment-gateway/essential-guide-to-integration)
auf fünf Drittanbieter. Von den erreichbaren Anbieterseiten ist
jedes Modul kostenpflichtig und Closed Source, ohne öffentliches
Repository und ohne Erwähnung von Hyvä.
[Eines](https://maghos.com/gopay-payment-for-magento-2.html)
unterstützt Magento nur bis 2.4.6, ein anderes (Artio, über die
Anbieterliste oben erreichbar) nennt Kompatibilität nur mit Magento
2.2.x auf PHP 7.0. Der Shop des fünften Anbieters war bei unserer
Prüfung nicht erreichbar, und die
[letzte archivierte Version](https://web.archive.org/web/20211203/https://connect20.aveo-trade.cz/details=1/extension=atconnect/magento-two-gopay)
seines Moduls stammt aus dem Februar 2019. Keiner der beiden
Hyvä-Tracker führt einen GoPay-Eintrag, keine erreichbare
Anbieterseite erwähnt GraphQL, und eine Suche im Adobe Commerce
Marketplace zeigt derzeit keine GoPay-Erweiterung. Das Gateway
selbst deckt ab, was ein tschechischer Checkout braucht
([Bank-Buttons, QR-Zahlungen, Wallets, Ratenzahlung](https://www.gopay.com/en/payment-methods/))
zu [veröffentlichten Preisen](https://www.gopay.com/en/pricing/),
per Redirect oder eingebettetem Overlay, je nach Modul des
Anbieters. Planen Sie die Integration als Individualarbeit mit
einem Drittanbieter ein, und prüfen Sie das Modul vor der
Inbetriebnahme, angefangen bei seiner Webhook-Verarbeitung.

**Comgate** folgt demselben Muster: Die eigene Dokumentation
delegiert das Magento-Modul an
[Platiti.cz](https://help.comgate.cz/docs/open-source-reseni), die
angebotenen Module sind kostenpflichtig und geschlossen, das einzige
öffentliche Repository ist ein
[inoffizielles](https://github.com/ppexxi/comgate_magento2), seit
2021 inaktiv, keiner der beiden Hyvä-Tracker führt einen
Comgate-Eintrag, und keine der beiden Anbieterseiten erwähnt
GraphQL oder Headless-Unterstützung. Der Standardablauf des
Gateways, ein Redirect auf Comgates gehostete Seite, hält den Shop
im kleinsten PCI-Geltungsbereich. Comgate bietet daneben auch
eingebettete Modi an, und mindestens eines der geschlossenen Module
wirbt damit, prüfen Sie also, welchen Ablauf das gekaufte Modul
tatsächlich nutzt. Die Methodenliste ist für die Region breit
aufgestellt: Karten, Wallets, BLIK, Ratenzahlung über Twisto und
Skip Pay, sowie, was
[Comgates Website](https://www.comgate.eu/cs/platebni-brana) als
umfassende Bankenabdeckung in Tschechien, der Slowakei und Polen
beschreibt. Bei Überweisungen und QR-Zahlungen liegt der Mehrwert
des Gateways gegenüber dem selbst generierten QR-Code, den viele
tschechische Shops bereits auf Rechnungen drucken, in der
sofortigen Bestätigung und dem automatischen Bestellabgleich. Die
Preise sind
[veröffentlicht](https://www.comgate.eu/cs/cenik-platebni-brany),
bis hin zur Chargeback-Gebühr.

**PayU** ist das einzige CEE-Gateway, das sein Magento-Modul so
pflegt wie die internationalen Anbieter:
[öffentliches Repository](https://github.com/PayU-EMEA/plugin_magento_24),
Apache 2.0, vom Anbieter gepflegt, nur Magento 2.4. Der Rhythmus ist
unregelmäßig, mit einer neunmonatigen Lücke zwischen Releases 2025
und 2026, dann vier Releases im Jahr 2026. Hyvä-Checkout-Unterstützung
existiert, ist aber ein Drittanbieterprodukt (Snowdog) und im
[offiziellen Tracker](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/work_items/553)
als unvollständig markiert, mit der letzten getaggten Version
(2.0.0) aus dem April 2024. Das Modul hat keine
GraphQL-Unterstützung. Seine Funktionsliste kennt keine
BLIK-spezifische Methode, sodass BLIK innerhalb des generischen
Redirects läuft, den
[PayUs Dokumentation](https://developers.payu.com/europe/docs/payment-solutions/blik/)
als auf Standard-Pay-by-Link begrenzt beschreibt; die
Code-Eingabe im Checkout und die One-Click-Varianten gehören zur
direkten API. Kartenzahlung erfolgt über ein On-Site-Formular, die
übrigen Methoden per Redirect. Polnische Preise sind
[veröffentlicht](https://poland.payu.com/en/pricing/).

**Przelewy24** pflegt sein Modul selbst, was es von den
tschechischen Gateways unterscheidet, auch wenn sich die Pflege
mangels öffentlichem Repository nicht beobachten lässt. Das aktuelle
Modul für Magento 2.4.4 und höher wird
[über den Marketplace vertrieben](https://commercemarketplace.adobe.com/przelewy24-magento2-przelewy24.html),
unter GPL-3.0-Label, ohne öffentliches Repository oder
Issue-Tracker und ohne Release-Daten je Version. Ältere Builds, eine
separate GraphQL-/PWA-/Vue-Variante sowie das anbietereigene
Hyvä-Checkout-Modul (v1.0.0, laut Seite datiert auf den 24. März
2026) sind
[von der eigenen Website herunterladbar](https://www.przelewy24.pl/en/download).
Wir haben beide Extras entpackt. Das Hyvä-Modul enthält
Magewire-Checkout-Komponenten für BLIK, Karten, Google Pay und Apple
Pay, aufbauend auf
`hyva-themes/magento2-hyva-checkout`. Die GraphQL-Variante (laut
Composer-Manifest Version 1.3.0, die Seite datiert sie auf den
9. Februar 2026) ist ein serverseitiges GraphQL-Modul, eingebunden
in Magentos Payment-Mutation, ohne PWA- oder Vue-Frontend-Code trotz
des Labels. Beide Extras fehlen in den Hyvä-Trackern, sodass
Tracker-Sichtbarkeit und First-Level-Support allein beim Anbieter
liegen. Die polnischen Wettbewerber TPay und PayPo haben Einträge im
Hyvä-Checkout-Tracker
([TPay](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/549),
[PayPo](https://gitlab.hyva.io/hyva-public/checkout-integration-tracker/-/issues/550)),
PayPos Modul wird von Snowdog gepflegt, TPays ist eine
Eigenentwicklung des Anbieters. Der Standardablauf ist ein Redirect,
mit optionaler Karten- und BLIK-Eingabe im Checkout. Die
dokumentierte BLIK-Unterstützung ist unter diesen Modulen die
vollständigste: Redirect, Code-Eingabe im Checkout und
One-Click-BLIK, alles laut Marketplace-Eintrag und Release Notes des
Anbieters. Die Standardpreise sind
[veröffentlicht](https://www.przelewy24.pl/bramka-platnicza).

## Im Vergleich

| Gateway | Modulpflege | Öffentlicher Quellcode | Hyvä Checkout | GraphQL | Öffentliche Preise |
| ------- | ----------------- | ------------- | ------------- | ------- | -------------- |
| Adyen | Anbieter | Ja | Hyvä-Namespace | Dokumentiert | Ja |
| Stripe | Anbieter | Nur Archive | Hyvä-Namespace | Im Quellcode | Ja |
| Mollie | Anbieter | Ja | Anbieter | Im Quellcode | Ja |
| Braintree (gebündelt) | Gene für PayPal | Nein | Hyvä-Namespace | Plattformpaket | Ja |
| Klarna | Anbieter | Nein | Hyvä-Namespace | Dokumentiert | Nein |
| Unzer | Anbieter | Ja | Anbieter, unversioniert | Nein | Einstiegstarife |
| GoPay | Drittanbieter | Nein | Keine gefunden | Nichts angegeben | Ja |
| Comgate | Drittanbieter | Nein | Keine gefunden | Nichts angegeben | Ja |
| PayU | Anbieter | Ja | Drittanbieter, unvollständig | Nein | Ja |
| Przelewy24 | Anbieter | Kein Repository | Anbieter, ungetrackt | Separater Build | Ja |

„Hyvä-Namespace“ bedeutet, dass das Integrationspaket unter
`hyva-themes` veröffentlicht ist, mit First-Level-Verantwortung
gemäß den Labels „Vendor“ und „Community“ des Checkout-Trackers. In
der GraphQL-Spalte bedeutet „Dokumentiert“, dass der Anbieter
Unterstützung angibt und wir den Code nicht gelesen haben; „Im
Quellcode“ bedeutet, dass wir es im öffentlichen Code gelesen haben;
„Plattformpaket“ bedeutet, dass es als eigenes Composer-Paket neben
der Plattform ausgeliefert wird, mit von Adobe dokumentierten
Abläufen. Przelewy24s GraphQL-Unterstützung erscheint als separates
herunterladbares Modul; wir haben es entpackt und eine serverseitige
GraphQL-API ohne Frontend-Code gefunden, trotz des PWA-Labels. Die
Braintree-Zeile bezieht sich auf die gebündelte Erweiterung; der
Quellcode des PayPal-Kernmoduls liegt öffentlich in Magento selbst.
Die Zellen folgen aus den oben verlinkten Quellen; „Nichts
angegeben“ und „Keine gefunden“ vermerken unsere eigenen
Recherchen. Alle Angaben Stand 2. August 2026.

## Vom Markt ausgehen, dann ausschließen

In Deutschland beziffert die Zahlungsstudie des EHI Retail
Institute den PayPal-Anteil am Umsatz im Online-Handel 2024 auf 28,5
Prozent, den Rechnungskauf auf 25,8 Prozent, die Lastschrift auf
17,3 Prozent und Kartenzahlung auf 12,3 Prozent
([EHI](https://www.ehi.org/presse/paypal-festigt-spitzenposition/)).
Ein deutscher Checkout braucht also PayPal, ein Rechnungsprodukt und
SEPA-Lastschrift, bevor irgendetwas anderes nötig wird. Braintree
deckt PayPal ab und, auf Magento 2.4.9, den Rechnungskauf über
Ratepay. Klarna und Unzer verkaufen beide das Rechnungsprodukt. Für
die Lastschrift stehen hier Unzer, Mollie, Adyen oder Stripe zur
Wahl, da Adobes Braintree-Dokumentation SEPA-Lastschrift als noch
nicht unterstützt führt. Der Ratepay-Weg setzt Magento 2.4.9 voraus,
das Adyens Plugin seit v10.10.0 unterstützt; die Kombination
funktioniert also auf einer aktuellen Plattform, und auf 2.4.8 und
darunter bleiben als Rechnungsoptionen Klarna und Unzer. Keiner der
drei Anbieter veröffentlicht einen Tarif für das Rechnungsprodukt
selbst: Braintrees deutsche Gebührenseite bepreist Karten und
Wallets ohne Ratepay-Zeile, Klarna veröffentlicht überhaupt keine
Liste, und Unzers Einstiegstarife sind allgemeine „ab“-Werte. Für die
zweitgrößte Methode des Marktes läuft der Gebührenvergleich also über
Angebote. Auf Karten entfiel etwa ein Achtel dieses Umsatzes. Ein
reiner Karten-Checkout büßt daher gegenüber Wettbewerbern Conversion
ein,
die die bevorzugten Methoden anbieten, selbst dort, wo Käufer auch
mit Karte zahlen könnten.

In Polen beziffert ein von BLIKs Betreiber in Auftrag gegebener
EY-Bericht den BLIK-Anteil am Wert der polnischen Online-Umsätze
2023 auf rund die Hälfte, gemessen über BLIK, Karten und
Überweisungen
([EY-Bericht für BLIK](https://www.blik.com/media/2025_03_12_EY_BLIK_payments_and_economy_report.pdf);
die Zahl stammt vom Betreiber selbst, gestützt auf Daten der
Zentralbank). Ein polnischer Checkout ohne BLIK verzichtet auf die
führende Online-Zahlungsmethode des Marktes. PayU, Przelewy24 und
Comgate unterstützen es nativ. Unter den internationalen Anbietern
führen Adyen und Mollie BLIK, Braintree hat es in Magento 2.4.9
ergänzt, und Stripes Moduldokumentation lässt es aus. Der
Großteil der Anbieter unterstützt BLIK in irgendeiner Form. Was die Optionen
in Polen unterscheidet, ist die BLIK-Tiefe (Redirect,
Checkout-Eingabe oder One-Click) und die Modulqualität. Przelewy24
dokumentiert die vollständigste Implementierung, mit der
Einschränkung aus seinem Profil: Sein Hyvä-Checkout-Modul wird von
der eigenen Website ausgeliefert und erscheint in keinem der beiden
Hyvä-Tracker, sodass First-Level-Support allein beim Anbieter liegt.

In Tschechien nutzen laut der 2024er-Welle von APEKs
Verbraucherumfrage, veröffentlicht in Shoptets Stav české
e-commerce, die Käufer am häufigsten Karten, mit 42 Prozent, gefolgt
von Google und Apple Pay mit 23, Nachnahme mit 13 und Überweisung
mit 12
([Live-Seite](https://www.ceska-ecommerce.cz/),
[archiviert](http://web.archive.org/web/20250401235543/https://www.ceska-ecommerce.cz/),
da die Live-Seite jährlich überschrieben wird; die Anteile stimmen
mit
[APEKs eigener 2024er-Reihe](https://data.apek.cz/)
überein). Jedes internationale Gateway deckt Karten und Wallets ab.
Die Bank-Buttons und QR-Zahlungen hinter einem Teil dieses
Überweisungsanteils tragen GoPay und Comgate, deren Magento-Module
die schwächsten der zehn sind. Die tschechische Frage lautet also,
ob der Anteil von Überweisung und Nachnahme ein zweites Gateway
überhaupt rechtfertigt: Ein internationaler Anbieter für Karten plus
ein lokales Gateway für Überweisungen kostet bei jedem Upgrade ein
zweites Modul, einen zweiten Abgleich samt Gebührenplan, und eine
methodenweise Deduplizierung im Checkout, da beide Seiten Karten und
Wallets anbieten. Die Kombination lohnt sich nur, wenn die
Ersparnis bei den Kartengebühren diesen Mehraufwand übersteigt. (Die
tschechischen und slowakischen Acquirer-seitigen Gateways, GP
webpay, ČSOB, TrustPay, bleiben außerhalb dieses Vergleichs; die
Bank-Button-Abdeckung läuft über GoPay und Comgate.) In der Slowakei
liegt die Nachnahme laut einer Analyse des E-Commerce-Plattformbetreibers
Upgates, gemeldet von der Nachrichtenagentur TASR im
[Juni 2026](https://www.teraz.sk/ekonomika/dobierky-predstavuju-pre-e-shopy-najna/973629-clanok.html),
weiterhin bei 25 bis 30 Prozent der Bestellungen. Das ist in erster
Linie eine Fulfillment-Entscheidung, betrifft aber über den
Abgleich mit dem Zustelldienst und die Offline-Zahlungsmethode
dennoch die Zahlungskonfiguration, und die oben genannten
Ratenzahlungsprodukte der Gateways sind die Antwort darauf. Die
Slowakei rechnet in Euro ab, was das Währungsargument für ein
lokales Gateway dort entfallen lässt.

Das Vorgehen lautet also: Listen Sie die von Ihrem Markt geforderten
Methoden auf, behalten Sie die Gateways, oder minimale Kombinationen
daraus, die diese Methoden gemeinsam abdecken, schließen Sie anhand
der oben genannten Modul- und Betriebskriterien aus, und vergleichen
Sie erst danach die Gebühren, samt Abrechnungswährung, unter den
verbliebenen Kandidaten.

Wenn Sie ein Gateway als Teil eines größeren Projekts auswählen oder
eines übernehmen, das ein Upgrade blockiert, ist diese Bewertung Teil
unserer [Magento-Leistungen](/de/services/magento/), und die Anbindung
eines Gateways an ein ERP- oder Abo-System deckt unser
[Integrationsservice](/de/services/integrations/) ab.