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, 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 für das Theme sowie einen eigenen Integrations-Tracker für Hyvä Checkout, und die Dokumentation listet die wichtigsten erfassten Zahlungsintegrationen auf. 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 ü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 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 (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 auf, darunter CZK und PLN, Mollie listet 13 Auszahlungswährungen, PayU rechnet in 11 Währungen 1:1 ab, und GoPay dokumentiert Auszahlungswährungen je Bank. Comgate veröffentlicht die Auszahlungsbedingungen je Währung, und Braintree veröffentlicht seine Liste der Schema-Währungen, wobei die je Händler geltende Auswahl beim Onboarding vereinbart und durch Anfrage weiterer Händlerkonten erweitert wird. Klarna zahlt in der Transaktionswährung aus. 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). 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 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, 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 noch die unkorrigierte Version 3.3.0, und erst am 13. Juni 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 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 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ä-Storefront verändert die Zahlungsfrage in einer Hinsicht. Mit dem Hyvä-Theme allein kann der Checkout über den dokumentierten Theme-Fallback 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 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). 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). 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 ö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 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 (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 abgedeckt, und die EU-Methodenabdeckung umfasst iDEAL, SEPA-Lastschrift, BLIK, Twint und Bancontact, wobei Karten als eingebettete Komponenten im Checkout dargestellt werden. Die Preise sind als Interchange++ 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 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), 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 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: 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, 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.

Mollie ist die stärkste Kombination aus Offenheit und Hyvä-Ausrichtung. Das Modul 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 und Hyvä Checkout, kündigte im Oktober 2024 eine strategische Partnerschaft mit Hyvä an und trägt über Open Collective finanziell zu Mage-OS bei, nennt dabei aber keine technische Mage-OS-Unterstützung. Das Release 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, 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 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 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), während Adobes Braintree-Seite 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. PayPal veröffentlicht die Braintree-Preise je Land: Die deutsche Gebührenseite nennt 1,9 % plus 0,30 EUR für Karten und Wallets von Drittanbietern zu Standard-Händlertarifen, denselben Wert wie die tschechische und die polnische Seite, allerdings ohne Tarif für die Ratepay-Rechnungsmethode. Die Legacy-Payflow-Methoden im Kernmodul sind von PayPal als Legacy markiert und laut Adobes Payflow-Pro-Seite 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 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 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 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 kennzeichnet sie als community-gepflegt. Die Release-Frequenz war 2026 hoch: von 4.1.1 im Januar (archivierter Eintrag) 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 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 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, 2.4.6 bis 2.4.8 in der Plugin-Übersicht). Die drei Hyvä-Repositories (magento2-hyva-checkout und verwandte) tragen keine Tags oder Releases und wurden zuletzt im Dezember 2025 aktualisiert, obwohl die Dokumentation ein Hyvä-Checkout-Plugin 1.0.0 mit Release im Februar 2026 angibt. Unzer veröffentlicht Einstiegstarife (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 eines der größten tschechischen und slowakischen Gateways, pflegt selbst kein Magento-Modul. Die Integrationsseite listet Erstanbieter-Module für Shoptet, WooCommerce, Shopify, OpenCart und PrestaShop. Für Magento verweist das Help Center 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 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 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) zu veröffentlichten Preisen, 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, die angebotenen Module sind kostenpflichtig und geschlossen, das einzige öffentliche Repository ist ein inoffizielles, 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 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, bis hin zur Chargeback-Gebühr.

PayU ist das einzige CEE-Gateway, das sein Magento-Modul so pflegt wie die internationalen Anbieter: öffentliches Repository, 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 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 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.

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

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). 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; 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, archiviert, da die Live-Seite jährlich überschrieben wird; die Anteile stimmen mit APEKs eigener 2024er-Reihe ü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, 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, und die Anbindung eines Gateways an ein ERP- oder Abo-System deckt unser Integrationsservice ab.