Kartenzahlung gehört heute zu den Standard-Zahlarten. Viele Shops binden dafür einen Payment Service Provider (PSP) ein – und sind damit „fertig“. In der Praxis entstehen aber oft Lücken: Kartendaten landen doch irgendwo im Shop, Tracking-Skripte laufen auf sensiblen Seiten oder Zuständigkeiten sind unklar. Genau hier setzt PCI DSS an: ein Sicherheitsstandard, der regelt, wie Kartendaten geschützt werden – unabhängig davon, ob ein kleiner WooCommerce-Shop oder ein großer Enterprise-Store betrieben wird.
PCI DSS verständlich erklärt: worum es wirklich geht
PCI DSS steht für „Payment Card Industry Data Security Standard“. Dahinter steckt ein Regelwerk, das die großen Kartenorganisationen (z. B. Visa, Mastercard) für den Umgang mit Kartendaten verlangen. Wichtig: Es geht nicht um „nice to have“, sondern um Anforderungen, die über den Zahlungsdienstleister vertraglich weitergereicht werden. Wer Kartenzahlung anbietet, muss in irgendeiner Form nachweisen, dass die eigenen Systeme Kartendaten nicht unnötig verarbeiten und angemessen geschützt sind.
Welche Daten sind gemeint?
Im PCI-Kontext zählen vor allem Daten, mit denen eine Karte missbraucht werden könnte: vollständige Kartennummer (PAN), Kartenprüfnummer (CVC/CVV) und ggf. Magnetstreifen-/Chipdaten. Viele Shops sollten solche Informationen nie selbst sehen. Ziel ist, Kartendaten konsequent beim PSP zu belassen.
Warum betrifft das auch kleine Shops?
„Wir sind zu klein“ ist leider kein Schutz. Sobald Kartenzahlung möglich ist, greifen die Pflichten. Der Unterschied liegt meist nicht im „Ob“, sondern im „Wie viel“: Wer Kartendaten komplett aus dem eigenen Shop heraushält, hat deutlich weniger Aufwand.
Scope reduzieren: der wichtigste Hebel für weniger Aufwand
Der Begriff „Scope“ beschreibt, welche Systeme in den PCI-Anwendungsbereich fallen. Je mehr im Scope ist, desto mehr muss dokumentiert, abgesichert und geprüft werden. Deshalb ist die wichtigste Strategie: Kartendaten so integrieren, dass der Shop sie gar nicht verarbeitet.
Praxis-Regel: Kartendaten gehören nicht in den Shop
Technisch bedeutet das: Zahlungsformulare sollten vom PSP gehostet werden oder als eingebettete Komponente laufen, die Kartendaten direkt an den PSP sendet (ohne Umweg über den Shop-Server). Gute Integrationen liefern Token (Platzhalter), aber keine Kartendaten. So bleibt der Shop aus dem kritischsten Teil heraus.
Typische Scope-Fallen im Alltag
- Selbst gebaute Checkout-Formulare, die Kartendaten an den Shop-Server senden.
- Server-Logs, Debug-Tools oder Fehlerreports, die versehentlich Kartendaten mitschneiden.
- „Bequeme“ Admin-Ansichten, in denen Kartendaten angezeigt oder exportiert werden.
- Plugins, die Zahlungsdaten in der Datenbank ablegen (auch temporär ist riskant).
Zahlungsintegration richtig wählen: Redirect, iFrame, API
Die Art der Zahlungsintegration entscheidet maßgeblich über Risiko und Pflichten. Dabei gibt es kein „immer richtig“, aber es gibt klare Muster, die in Shops gut funktionieren.
Redirect (Weiterleitung) – einfach, oft am sichersten
Beim Redirect werden Kund:innen für die Zahlung auf eine Seite des PSP geführt. Vorteil: Kartendaten bleiben zuverlässig außerhalb des Shops. Nachteil: Der Wechsel kann sich weniger „nahtlos“ anfühlen, ist aber heute für viele Nutzer:innen normal.
Embedded Payment (iFrame/Hosted Fields) – guter Kompromiss
Hier bleibt der Checkout optisch im Shop, aber die sensiblen Felder kommen technisch vom PSP. Damit lassen sich Conversion und Branding oft gut verbinden, ohne Kartendaten im Shop zu verarbeiten. Wichtig ist saubere Einbindung (keine eigenen Felder „nachbauen“).
Direkte API-Integration – nur mit klarer Sicherheitskompetenz
Bei direkter Anbindung verarbeitet der Shop-Server oft mehr als nötig. Das kann sinnvoll sein, etwa bei komplexen Zahlungsflüssen oder besonderen Anforderungen. Dann steigen aber auch Sicherheits- und Nachweispflichten. Ohne belastbares Sicherheitskonzept wird das schnell teuer und riskant.
Was Shop-Betreiber organisatorisch klären müssen
PCI ist nicht nur Technik. Häufig scheitert es an Zuständigkeiten und Prozessen. Wer weiß, wer im Incident-Fall handelt? Wer pflegt Zugangsdaten? Wer prüft Updates?
Rollen und Zugriffe: weniger ist mehr
Ein Kernprinzip ist Zugriffsbeschränkung: Nur Personen, die es wirklich brauchen, sollten Admin-Rechte haben. Für Dienstleister gilt: eigene Accounts statt geteilter Logins, klare Berechtigungen, Entzug bei Projektende.
Patch- und Update-Routine
Viele Angriffe nutzen bekannte Schwachstellen. Shops sollten deshalb ein verbindliches Update-Fenster haben: CMS/Shop-System, Plugins/Apps, Server-Komponenten. In der Praxis hilft eine Staging-Umgebung, um Updates vorab zu testen (siehe WooCommerce Staging-Umgebung einrichten).
Monitoring und Logik im Fehlerfall
Wenn Zahlungsvorgänge plötzlich scheitern oder ungewöhnliche Muster auftreten, braucht es schnelle Reaktion. Dazu gehören grundlegendes Monitoring (Uptime, Fehlerquoten), aber auch ein Plan: Welche Systeme werden geprüft, wer kontaktiert den PSP, wie wird der Checkout abgesichert?
Technische Mindestmaßnahmen, die in Shops fast immer sinnvoll sind
Die genauen PCI-Anforderungen hängen vom Integrationsmodell ab. Dennoch gibt es Maßnahmen, die unabhängig vom Detailgrad fast immer dazugehören, weil sie typische Angriffspfade schließen.
HTTPS überall und konsequent
Ein Shop sollte vollständig per HTTPS laufen, inklusive Checkout, Warenkorb und Account. Mischinhalte (HTTP-Ressourcen) sollten ausgeschlossen werden. Das reduziert Manipulationsrisiken und verhindert, dass Inhalte unterwegs verändert werden.
Checkout-Skripte im Blick behalten
Viele Shops laden im Checkout Marketing- und Tracking-Skripte nach. Das kann gefährlich werden, wenn Dritt-Skripte kompromittiert werden. Deshalb gilt: Im Checkout nur das Nötigste laden, und Tracking sauber strukturieren. Hilfreich ist ein klares Event-Konzept (siehe Shop-Tracking ohne Chaos).
Starke Admin-Sicherheit
Admin-Zugänge sind ein beliebtes Ziel. Sinnvolle Basics: starke Passwörter, Zwei-Faktor-Login (2FA), IP-Restriktionen wo möglich, und eine klare Trennung zwischen Admin- und Redaktionszugängen. Wer das Kundenkonto sicherer machen will, findet zusätzlich Ansatzpunkte unter Shop-Login optimieren.
So geht’s: PCI-Aufwand im Shop pragmatisch reduzieren
- Zahlungsanbieter so anbinden, dass Kartendaten nie über den Shop-Server laufen (Redirect oder Hosted Fields).
- Im Checkout nur notwendige Skripte laden; Third-Party-Tools kritisch prüfen.
- Admin-Zugriffe minimieren: 2FA, Rollen, getrennte Accounts für Dienstleister.
- Updates verbindlich planen und vor dem Livegang testen (Staging nutzen).
- Logs/Debugging prüfen: Keine sensiblen Daten mitschreiben oder speichern.
- Dokumentation schlank halten: Integrationsweg, Zuständigkeiten, Kontaktkette zum PSP.
Plattform-Hinweise: Shopify, WooCommerce, Shopware, Magento
Die Grundlogik ist in allen Systemen gleich: Scope klein halten, Checkout absichern, Rollen sauber steuern. Dennoch gibt es typische Unterschiede in der Praxis.
Shopify: viel Scope ist bereits ausgelagert
Bei Shopify liegt vieles in der Plattform. Trotzdem sollte der Checkout nicht „zugemüllt“ werden: Apps und Tracking-Erweiterungen sorgfältig auswählen, besonders wenn sie Checkout-Nähe haben. Eine gute Praxis ist, Apps nach Nutzen zu priorisieren und unnötige zu entfernen (siehe Shopify Apps sinnvoll einsetzen).
WooCommerce: Plugin-Landschaft sauber halten
WooCommerce ist flexibel, aber genau das ist die Herausforderung. Zahlungs-Plugins sollten aus vertrauenswürdigen Quellen stammen und aktiv gepflegt sein. Außerdem lohnt sich ein Performance- und Sicherheitsblick auf den gesamten Shop, weil langsame oder instabile Seiten oft mit mehr Drittcode einhergehen (siehe WooCommerce Performance optimieren).
Shopware 6: Prozesse und Integrationen zentral denken
Bei Shopware entstehen PCI-Risiken häufig über Integrationen: zusätzliche Sales Channels, Custom Plugins oder externe Checkouts. Wer Automatisierungen nutzt, sollte Payment-nahe Prozesse besonders sorgfältig prüfen, damit keine sensiblen Daten in Workflows landen.
Magento: hohe Flexibilität, hohe Verantwortung
Magento wird häufig stark angepasst. Das ist möglich, erhöht aber den Anspruch an saubere Entwicklungsprozesse (Code Reviews, sichere Deployments, getrennte Umgebungen). Gerade bei individuellen Payment-Anbindungen sollte klar dokumentiert sein, welche Komponenten Kartendaten berühren und welche nicht.
Checkliste: PCI-Risiken im Checkout schnell erkennen
- Werden Kartendaten im eigenen Formular erfasst oder immer beim PSP?
- Gibt es Stellen, an denen Kartendaten gespeichert, geloggt oder versendet werden könnten?
- Läuft im Checkout unnötiges Tracking oder fremder JavaScript-Code?
- Ist der Admin-Bereich mit 2FA und Rollen abgesichert?
- Gibt es eine Update-Routine und eine Testumgebung?
- Ist der Support-Kontakt zum PSP dokumentiert (inkl. Notfallweg)?
FAQ: häufige Fragen zu PCI DSS im Shop
Reicht es, wenn der Zahlungsanbieter „PCI-konform“ ist?
Ein PCI-konformer PSP ist eine wichtige Grundlage, aber nicht automatisch die komplette Lösung. Entscheidend ist, ob der eigene Shop Kartendaten verarbeitet oder ob sie technisch beim PSP bleiben. Je mehr ausgelagert ist, desto weniger bleibt beim Shop hängen.
Darf ein Shop Kartendaten speichern, um wiederkehrende Kunden schneller zahlen zu lassen?
In der Praxis sollte ein Shop Kartendaten nicht selbst speichern. Üblich sind Token-Lösungen: Der PSP speichert sicher und gibt dem Shop nur einen Token zurück. Damit sind wiederkehrende Zahlungen möglich, ohne dass Kartendaten im Shop liegen.
Was ist der größte Fehler in der Praxis?
Meist ist es nicht „zu wenig Technik“, sondern eine unklare Einbindung: Plugins, Custom-Code oder Debugging führen dazu, dass sensible Daten unbeabsichtigt verarbeitet werden. Darum ist der Scope-Check vor Go-live so wichtig.
Wie passt Betrugsschutz dazu?
Betrugsschutz (Fraud Prevention) ergänzt PCI: PCI schützt Kartendaten, Betrugsschutz reduziert Missbrauch wie gestohlene Karten oder Fake-Bestellungen. Beide Themen greifen im Checkout ineinander, sind aber nicht dasselbe. Für Maßnahmen gegen Chargebacks hilft der Überblick unter Betrugsschutz im Online-Shop.
Mini-Fallbeispiel: weniger Scope, weniger Stress
Ein kleiner Shop nutzt WooCommerce und wollte das Checkout-Design „perfekt“ anpassen. Dafür wurde ein eigenes Kreditkartenformular gebaut, das Daten an den Server sendete, bevor sie an den PSP gingen. Ergebnis: Der Shop war plötzlich deutlich stärker im PCI-Scope, und es mussten zusätzliche Sicherheitsmaßnahmen und Nachweise organisiert werden. Nach Umstellung auf Hosted Fields lief die Zahlung weiterhin im Markenlook, aber Kartendaten gingen direkt zum PSP. Der Scope schrumpfte, und die Wartung wurde einfacher.
Als Faustregel gilt: Je weniger Systeme Kartendaten berühren, desto einfacher werden Sicherheit, Dokumentation und Betrieb. Wer das von Anfang an so plant, spart später Zeit – und reduziert vermeidbare Risiken rund um Kartenzahlung im Checkout.
