PCI-DSS: Was Händler wirklich tun müssen · Zahlungskompass
Zahlungskompass Echte Kosten berechnen
Ratgeber

PCI-DSS: Was Händler wirklich tun müssen

PCI-DSS verpflichtet jeden, der Kartenzahlungen akzeptiert. Was das für Händler mit einem Terminal bedeutet — und wann der Anbieter die Arbeit übernimmt.

Von Ulf Mayer 14. Juli 2026 4 Min. Lesezeit
Kreditkarte wird in ein Kartenterminal gesteckt — PCI-DSS schützt die Kartendaten bei jeder Transaktion

Wer Kartenzahlungen akzeptiert, ist automatisch an den Payment Card Industry Data Security Standard (PCI-DSS) gebunden — das ist keine Behördenvorschrift, sondern eine vertragliche Anforderung von Visa und Mastercard. Hält ein Händler PCI-DSS nicht ein und es kommt zu einem Datenleck, haftet er vollständig.

Die gute Nachricht für die meisten Kleinhändler: Wer einen zertifizierten Terminalhersteller nutzt und Kartendaten nie auf eigenen Systemen sieht, hat kaum eigene Arbeit.

Was PCI-DSS ist — und was nicht

PCI-DSS ist ein Sicherheitsstandard, der vorschreibt, wie mit Kartendaten (Kartennummer, Ablaufdatum, CVC) umgegangen werden muss. Er wird von der PCI Security Standards Council verwaltet, einem Zusammenschluss von Visa, Mastercard, Amex, Discover und JCB.

PCI-DSS ist kein nationales Gesetz — es gibt keine Behörde, die es direkt durchsetzt. Die Durchsetzung läuft über den Acquirer: Wer bei ihm einen Akzeptanzvertrag hat, verpflichtet sich vertraglich zur PCI-Konformität. Bei Verstößen können Acquirer Bußgelder weitergeben, die die Kartennetzwerke verhängt haben.

Vier Händler-Level

PCI-DSS unterteilt Händler in vier Level nach dem jährlichen Kartentransaktionsvolumen:

LevelTransaktionen/JahrAnforderung
1über 6 MillionenJährliches Audit durch zugelassenen QSA-Prüfer
21–6 MillionenJährlicher SAQ + quartalsweiser Netzwerkscan
320.000–1 Million (E-Commerce)Jährlicher SAQ + quartalsweiser Scan
4unter 1 Million / unter 20.000 (E-Com)Jährlicher SAQ, Scan auf Empfehlung

Die überwiegende Mehrheit der Händler in Deutschland fällt in Level 4 — der einzige, bei dem ein einfacher Selbstauskunftsbogen ausreicht.

Was Händler in der Praxis tun müssen

Der konkrete Aufwand hängt davon ab, wie Kartendaten fließen — und vor allem, ob der Händler sie überhaupt zu sehen bekommt.

Fall 1: Zertifiziertes Terminal, kein eigenes System (Normalfall)

Ein Händler nutzt SumUp, Zettle, Flatpay, PAYONE oder ein anderes zertifiziertes Terminal. Kartendaten werden vom Terminal verschlüsselt und direkt an den Zahlungsdienstleister übertragen — der Händler sieht zu keinem Zeitpunkt die eigentliche Kartennummer.

Anforderung: SAQ A oder SAQ P2PE — wenige Seiten, einmal jährlich. Kein externer Prüfer, kein Netzwerkscan.

Fall 2: Eigenes System verarbeitet Kartendaten (E-Commerce)

Ein Händler betreibt einen eigenen Webshop, der Kartendaten entgegennimmt (auch wenn nur für Millisekunden). Hier erweitert sich der sogenannte Cardholder Data Environment (CDE) erheblich — alle Systeme, die Kartendaten sehen könnten, müssen PCI-DSS-konform betrieben werden.

Anforderung: SAQ D (umfangreich, 200+ Fragen) oder Einbindung eines PCI-zertifizierten Zahlungs-Gateways (Stripe, Mollie, Adyen), das dafür sorgt, dass Kartendaten nie das eigene System berühren (iFrame, Hosted Fields, Redirect).

Empfehlung: Wer keinen überzeugenden technischen Grund hat, Kartendaten selbst zu verarbeiten, sollte es nicht tun. Die Einbindung von Stripe.js, Mollie Components oder Adyen Web Components verschiebt die gesamte PCI-Last auf den Zahlungsdienstleister — der eigene Scope reduziert sich auf SAQ A.

Fall 3: Kombination aus Terminal und Webshop

Hier gilt der Scope für jeden Kanal separat. Wer das Terminal sauber trennt und den Webshop über Hosted-Fields-Integration abwickelt, kann in beiden Bereichen mit schlanken SAQ-Typen auskommen.

Der SAQ — in der Praxis

Der Selbstauskunftsbogen (SAQ) hat verschiedene Varianten je nach Setup. Die häufigsten für kleine und mittlere Händler:

SAQ-TypSituationFragen ca.
SAQ ANur Redirects/iFrames, keine eigene Kartenverarbeitung22
SAQ P2PENur P2PE-zertifizierte Terminals (Ingenico, PAX etc.)34
SAQ BNur Terminals, Telefonbestellungen — keine E-Commerce41
SAQ CZahlungssoftware auf eigenem System, kein E-Commerce80
SAQ DEigene Speicherung oder Verarbeitung, E-Commerce200+

In der Praxis bekommen viele Kleinhändler den SAQ jährlich von ihrem Acquirer per E-Mail — mit dem Link zu einem Onlineformular, das in 15–30 Minuten ausgefüllt ist.

Was passiert bei Verstößen

PCI-DSS-Verstöße werden in der Regel erst sichtbar, wenn es zu einem Datenleck kommt. Dann greift die volle Haftungskette:

  1. Fines & Fines: Kartennetzwerke verhängen Bußgelder beim Acquirer — zwischen 5.000 und 100.000 € pro Monat, bis der Verstoß behoben ist.
  2. Weiterleitung an den Händler: Der Acquirer leitet die Kosten vertraglich an den Händler weiter.
  3. Kartenersatzkosten: Alle betroffenen Karten müssen neu ausgestellt werden. Der nicht-konforme Händler trägt in der Regel diese Kosten.
  4. Forensische Untersuchung: Bei Level-1-Vorfällen (großflächige Datenlecks) ist ein forensisches Audit Pflicht — auf Kosten des Händlers.

Für Händler, die ausschließlich zertifizierte Terminals und Zahlungsdienstleister nutzen, ist dieses Szenario nahezu ausgeschlossen: Die Kartendaten waren nie auf ihren Systemen.

Was PCI-DSS für die Terminal-Wahl bedeutet

Alle relevanten Terminalhersteller und Zahlungsdienstleister in Deutschland — SumUp, Zettle, myPOS, Flatpay, PAYONE, Nexi, Viva.com — sind PCI-zertifiziert. Als Händler trägst du hier keine eigene Zertifizierungslast.

Relevant wird PCI-DSS in der Terminal-Wahl, wenn du nach dem Backend fragst:

  • Eigenentwicklungen oder Legacy-Systeme ohne PCI-Zertifizierung erweitern den Scope erheblich.
  • Kassensysteme (orderbird, ready2order, Lightspeed) verarbeiten keine Kartendaten selbst, wenn sie über ein separates, PCI-zertifiziertes Terminal abrechnen — der Scope bleibt minimal.
  • Webshops mit eigener Karteneingabe (kein iFrame, kein Redirect) fallen in SAQ D: Das ist der häufigste Fehler bei Händlern, die ihren Checkout selbst gebaut haben.

TSE-Pflicht: Was Händler zur Kassensicherung wissen müssen
Chargeback: Wie Rückbuchungen funktionieren und was Händler tun können
Was ist ein Acquirer? Die Händlerbank hinter dem Terminal
Kassensystem & Buchhaltung: Welche Schnittstellen wirklich funktionieren

Häufige Fragen

Muss ich als kleiner Händler PCI-DSS einhalten?

Ja — PCI-DSS gilt für jeden, der Kartenzahlungen akzeptiert, unabhängig von der Größe. Wie aufwendig die Einhaltung ist, hängt vom Level ab. Händler mit einem zertifizierten Terminal-Anbieter (SumUp, Zettle, Flatpay etc.) müssen in der Regel nur einen kurzen Selbstauskunftsbogen (SAQ) ausfüllen und sind damit konform.

Was ist der SAQ und muss ich ihn wirklich ausfüllen?

SAQ steht für Self-Assessment Questionnaire — ein Selbstauskunftsbogen, den Händler jährlich ausfüllen, um ihre PCI-DSS-Konformität zu bestätigen. Wer ausschließlich über zertifizierte Terminals mit Kartenlesegeräten kassiert und Kartendaten nie selbst verarbeitet oder speichert, füllt den SAQ P2PE aus — er hat weniger als 35 Fragen.

Gilt PCI-DSS auch für Tap to Pay auf dem Smartphone?

Ja — auch Tap-to-Pay-Lösungen wie SumUp Tap to Pay oder Viva.com SoftPOS müssen PCI-zertifiziert sein. Die Zertifizierung liegt beim Anbieter, nicht beim Händler. Als Händler nutzt du eine bereits zertifizierte Lösung; eigene PCI-Zertifizierung ist nicht nötig.

Was passiert, wenn ich PCI-DSS nicht einhalte?

Bei einem Datenleck können Acquirer und Kartennetzwerke hohe Bußgelder verhängen — in schweren Fällen 5.000–100.000 € pro Monat bis zur Behebung. Zusätzlich trägt der nicht-konforme Händler die vollen Kosten für Kartenersatz bei betroffenen Kunden. In der Praxis betrifft das Kleinhändler mit zertifizierten Anbietern kaum — das Risiko liegt bei selbst entwickelten Checkout-Lösungen.

Muss ich Kartendaten selbst speichern, um PCI-relevant zu sein?

Nein — PCI-DSS greift bereits beim Verarbeiten oder Durchleiten von Kartendaten, nicht nur beim Speichern. Wer jedoch ausschließlich zertifizierte Terminals und Payment-Dienstleister nutzt und Kartendaten nie auf eigenen Systemen sieht, hat einen deutlich eingeschränkten Geltungsbereich (Scope) und damit auch deutlich geringere Anforderungen.