Was ein Zahlungsmodul in Shopware übernimmt
Ein Zahlungsmodul trägt in Shopware nicht nur den Bezahlvorgang, sondern den ganzen Lebenslauf einer Bestellung: Es meldet den Warenkorb beim Abwickler an, führt den Kunden durch die Bezahlung, nimmt das Ergebnis entgegen und setzt den Zahlungsstatus der Bestellung. Erstattungen, Teilerstattungen und Stornos lösen Sie danach in der Shopware-Administration aus, nicht in einem zweiten Portal.
Der Wert steckt in den Fällen daneben. Eine abgebrochene Zahlung, eine verspätete Statusmeldung, eine Rücksendung mit Teilerstattung, eine Nachbestellung auf dieselbe Zahlung — ein gepflegtes Modul hat diese Abläufe bereits abgebildet und schreibt die Zustände dorthin, wo Shopware sie erwartet. Genau daran scheitern Eigenbauten regelmäßig, nicht am Bezahlen selbst.
Für Sie heißt das: Die Auswahl des Moduls ist keine reine Preisfrage. Entscheidend sind die unterstützten Shop-Versionen, die abgedeckten Zahlungsarten und die Frage, wie schnell das Modul nach einem Shopware-Update nachzieht.
Versionsstände sind bei Shopware kein Detail
Shopware 6 ist keine einzelne Version, sondern eine Reihe. Zwischen den Nebenversionen gibt es Änderungen, die genau die Stellen betreffen, an denen ein Zahlungsmodul andockt. Ein Modul, das für eine ältere Nebenversion gebaut wurde, kann deshalb im Checkout unauffällig danebenliegen, ohne dass eine Fehlermeldung erscheint.
Wie eng die Anbieter das führen, lässt sich an veröffentlichten Kompatibilitätslisten ablesen. Ein etablierter Gateway-Anbieter dokumentiert für sein Shopware-6-Modul in der Version 7.1.10 die unterstützten Shop-Versionen 6.5.x bis 6.7.x (Unzer, Plugin-Dokumentation, Abrufstand 1. August 2026). Das ist die Art von Angabe, die vor einem Projekt auf den Tisch gehört — und die Sie von jedem Anbieter verlangen können.
Praktische Folge: Bevor irgendetwas installiert wird, steht die genaue Nebenversion Ihres Shops fest, samt der Frage, ob in den nächsten Monaten ein Versionssprung ansteht. Ein Sprung nach der Anbindung ist beherrschbar, ein Sprung mitten in der Anbindung kostet den Projektplan.
Vier Wege, die Zahlungsstrecke anzubinden
Alle vier sind mit Shopware machbar. Sie unterscheiden sich im Aufwand, in der Gestaltungsfreiheit und — am folgenreichsten — im Prüfaufwand nach dem Kartensicherheitsstandard.
- 01Fertiges Modul
- Der schnellste Weg, ohne Programmierung. Installieren, Zugangsdaten eintragen, Zahlungsarten aktivieren, testen. Geeignet für einen Standardshop ohne Sonderprozesse. Werden die Kartendaten dabei in einem Fenster des Abwicklers erfasst, bleiben Sie im einfachsten Selbstauskunftsverfahren.
- 02Gehostete Bezahlseite
- Der Kunde wird zur Bezahlseite des Abwicklers geführt und danach zurückgeleitet. Optisch ein sichtbarer Wechsel, dafür der geringste Aufwand auf Ihrer Seite und ebenfalls das einfachste Prüfverfahren. Für Shops ohne eigene Entwicklung die ruhigste Lösung.
- 03Eingebettetes Formular
- Die Bezahlfelder liegen im Layout Ihres Shops, der Kunde bleibt sichtbar bei Ihnen. Liegt das Eingabefeld in einem eingebetteten Fenster des Abwicklers, bleibt es beim einfachsten Verfahren; wird das Formular selbst gehostet, gilt die erweiterte Variante. Der typische Weg für agenturbetreute Projekte mit Anspruch an das Erscheinungsbild.
- 04Direkte Anbindung an die Schnittstelle
- Maximale Freiheit, maximaler Aufwand. Sie verarbeiten Kartendaten selbst und fallen damit in das umfangreichste Prüfverfahren. Für Shopware-Projekte ist das nur bei sehr großen Händlern mit eigener IT eine sinnvolle Wahl.
Was der Integrationsweg für den Prüfaufwand bedeutet
Der Unterschied zwischen dem einfachsten und dem umfangreichsten Selbstauskunftsbogen ist für einen Mittelständler ein fünfstelliger Betrag pro Jahr an Prüf- und Scankosten. Diese Tabelle ist deshalb die teuerste Entscheidung auf dieser Seite.
| Integrationsweg | Selbstauskunftsbogen | Aufwand für Sie |
|---|---|---|
| Gehostete Bezahlseite | A | am geringsten — Kartendaten berühren Ihre Systeme nie |
| Modul mit eingebettetem Fenster des Abwicklers | A | gering, bei vollem Erscheinungsbild Ihres Shops |
| Selbst gehostetes Formular mit Tokenisierung | A-EP | jährlich auszufüllen, deutlich umfangreicher |
| Direkte Anbindung an die Schnittstelle | D | am höchsten — Sie verarbeiten Kartendaten selbst |
| Manuelle Eingabe im Händlerportal | C-VT | ausdrücklich nur als Ausnahmefall vorgesehen |
Zuordnung nach der öffentlichen Dokumentation eines internationalen Zahlungsdienstleisters, Abrufstand 1. August 2026. Welcher Bogen im Einzelfall gilt, entscheidet die konkrete Umsetzung — nicht der Produktname.
Shopware Payments: wenn das Shopsystem selbst zum Anbieter wird
Shopware bietet inzwischen eine eigene, nativ integrierte Bezahllösung an, aufgebaut auf der Infrastruktur von PayPal. Abgerechnet wird rein transaktionsbasiert, ohne zusätzliche Lizenzkosten; für das PayPal-Wallet werden keine Zusatzkosten genannt. Verfügbar ist das Angebot derzeit in Deutschland und Österreich, weitere EU-Märkte und die USA sind angekündigt (Shopware, Produktseite, Abrufstand 1. August 2026).
Für einen reinen Onlinehändler ist das ein ernstzunehmendes Angebot, und wir sagen das offen. Die Anbindung ist naturgemäß eng, und ein Vertrag weniger ist ein echter Vorteil. Wer ausschließlich online verkauft, sollte es prüfen, statt es zu ignorieren.
Die Grenze liegt dort, wo der Kunde im Laden steht. Eine Bezahllösung des Shopsystems bedient den Shop, nicht den Verkauf vor Ort. Ein Betrieb mit beidem hat dann zwei Verträge, zwei Abrechnungen, zwei Ansprechpartner und zwei getrennte Auswertungen — und muss den Umsatz am Monatsende selbst zusammenführen. Genau das ist der Fall, in dem ein gemeinsamer Vertrag für beide Kanäle die einfachere Lösung ist.
Wer macht was bei einer Shopware-Anbindung
Shopware-Projekte laufen überwiegend über eine Agentur. Die häufigste Verzögerung entsteht nicht an der Technik, sondern an der Frage, wer auf wen wartet.
| Aufgabe | Zuständig | Was schiefgeht, wenn es unklar bleibt |
|---|---|---|
| Genaue Shop-Version und geplante Sprünge benennen | Händler und Agentur | Das Modul passt nicht zur Nebenversion und der Fehler zeigt sich erst im Checkout. |
| Zugangsdaten für die Testumgebung bereitstellen | Abwickler | Die Agentur beginnt ohne Testdaten und muss später alles wiederholen. |
| Modul installieren und konfigurieren | Agentur oder Shopbetreuer | Halbfertige Konfigurationen gehen live, weil niemand den letzten Schritt verantwortet. |
| Zahlungsarten und deren Reihenfolge festlegen | Händler | Der Checkout bietet Zahlungsarten an, die im Zielmarkt niemand nutzt. |
| Testbestellungen über alle Zahlungsarten | Agentur mit dem Händler | Erstattung und Storno werden nie getestet — und fallen im Echtbetrieb auf. |
| Freigabe für den Livegang | Händler | Der Termin verschiebt sich, weil die Freigabe niemandem zugeordnet war. |
Was vor der Anbindung feststehen sollte
Sechs Angaben, mit denen ein Anbindungsgespräch in einer Sitzung abgeschlossen ist statt in dreien.
- 01Shop-Version und Hosting
- Die genaue Nebenversion, wo der Shop läuft und wer ihn technisch betreut. Ohne diese drei Angaben lässt sich keine verbindliche Aussage zur Kompatibilität treffen.
- 02Gewünschte Zahlungsarten
- Welche Zahlungsarten Sie anbieten wollen und welche davon in Ihrem Zielmarkt tatsächlich nachgefragt werden. Jede zusätzliche Zahlungsart bedeutet Einrichtung, Test und Pflege.
- 03Integrationsweg
- Fertiges Modul, gehostete Seite, eingebettetes Formular oder direkte Anbindung. Diese Entscheidung bestimmt den Prüfaufwand nach dem Kartensicherheitsstandard und lässt sich später nur mit Aufwand ändern.
- 04Wiederkehrende Beträge
- Ob Abonnements, Raten oder Mitgliedsbeiträge abgerechnet werden. Das ist kein Schalter im Modul, sondern eine eigene Strecke mit eigenen Regeln zur Authentifizierung und Haftung.
- 05Ladengeschäft im Spiel
- Ob dieselben Waren auch vor Ort verkauft werden und ob Abholung, Rückgabe im Laden oder Gutscheine kanalübergreifend funktionieren sollen. Das entscheidet darüber, ob Shop und Verkauf vor Ort überhaupt getrennt gedacht werden dürfen.
- 06Testfälle
- Nicht nur die erfolgreiche Bestellung, sondern auch Abbruch, Erstattung, Teilerstattung und Storno. Diese vier Fälle sind die, die im Echtbetrieb Aufwand erzeugen — und die in Testläufen am häufigsten fehlen.
Häufige Fragen zu Shopware und Zahlung
Welche Shopware-Versionen werden unterstützt?
Das hängt am Modul, nicht am Shop. Ein etablierter Anbieter dokumentiert für sein aktuelles Shopware-Modul die Shop-Versionen 6.5.x bis 6.7.x (Abrufstand 1. August 2026). Verlangen Sie diese Angabe vor dem Projekt schriftlich — sie ist der Unterschied zwischen einer Anbindung und einer Fehlersuche.
Wir nutzen Shopware 5. Geht das auch?
Ältere Hauptversionen werden von Zahlungsmodulen nach und nach nicht mehr unterstützt. Wenn Sie ohnehin vor einem Versionswechsel stehen, ist es meist sinnvoller, die Zahlungsstrecke gleich auf der Zielversion aufzubauen, statt sie zweimal zu bauen. Das ist eine Projektfrage, keine Produktfrage — und sie gehört vor die Auswahl des Anbieters.
Wer installiert das Modul?
In der Regel die Agentur oder der technische Betreuer Ihres Shops. Die Installation selbst ist der kleinere Teil; die Arbeit steckt in der Konfiguration, in den Testbestellungen und in der Abstimmung mit der Warenwirtschaft.
Was passiert bei einem Shopware-Update?
Prüfen Sie vor dem Update, ob das Zahlungsmodul die Zielversion unterstützt, und testen Sie die Zahlungsstrecke danach auf einer Kopie, bevor der Shop umgestellt wird. Das ist der einzige Punkt, an dem ein Shopware-Update die Zahlung ernsthaft treffen kann — und er ist vollständig planbar.
Lohnt sich Shopware Payments statt eines eigenen Anbieters?
Wenn Sie ausschließlich online verkaufen, ist es eine ernstzunehmende Option, und wir raten davon nicht pauschal ab. Sobald ein Ladengeschäft dazukommt, ändert sich die Rechnung: Die Lösung des Shopsystems bedient den Verkauf vor Ort nicht, und Sie führen zwei getrennte Abrechnungen. Dann ist ein Vertrag für beide Kanäle der einfachere Weg.
Können wir mehrere Zahlungsarten unterschiedlich behandeln?
Ja. Shopware erlaubt es, Zahlungsarten je nach Bedingung anzubieten oder auszublenden — etwa nach Warenkorbwert, Kundengruppe oder Lieferland. Was davon sinnvoll ist, klärt sich am Sortiment: Jede ausgeblendete Zahlungsart ist ein Kaufabbruch weniger oder mehr, je nachdem, für wen sie ausgeblendet wird.
Stand und Herkunft der Angaben
Die genannten Versionsstände stammen aus der öffentlichen Plugin-Dokumentation eines Gateway-Anbieters, die Angaben zu Shopware Payments von der Produktseite des Herstellers, die Zuordnung der Selbstauskunftsbögen aus der öffentlichen Dokumentation eines internationalen Zahlungsdienstleisters. Alle drei mit Abrufstand 1. August 2026.
Versionsstände ändern sich schnell. Verstehen Sie die Zahlen auf dieser Seite als Beispiel dafür, wie genau eine Kompatibilitätsangabe aussehen muss — nicht als Zusage für Ihr Projekt. Verbindlich ist immer die Auskunft für Ihre konkrete Shop-Version zum Zeitpunkt der Anbindung.