Englisch
Deutsch
Spanisch
Französisch
Türkisch
Zurück zu Leitfäden
PCI-DSS-Compliance für Payment-Gateways: Der Leitfaden 2026 für deutsche Händler
PCI DSS v4.0.1 ist seit dem 31.03.2025 in allen Kontrollen verpflichtend. Wer Kartenzahlungen akzeptiert, ist im Scope. Die einzige Frage ist, wie tief. Der Gateway-Typ entscheidet stärker als die Unternehmensgröße, ob PCI-Compliance 10 Minuten Fragebogen oder ein Audit mit sechsstelligem Jahresbudget bedeutet.
Dieser Leitfaden erklärt die 12 Kernanforderungen, die vier Merchant-Level, die acht SAQ-Typen und die Architekturentscheidungen, die Ihren Scope reduzieren. Plus: Wie Krypto-Payment-Gateways den PCI-Scope für das Krypto-Bein vollständig eliminieren und sich in das deutsche Rahmenwerk aus MaRisk, BAIT/ZAIT und DORA einfügen.
Steigern Sie Ihr Geschäft durch die Annahme von Krypto-Zahlungen
Was ist PCI DSS und wer setzt es durch?
Der Payment Card Industry Data Security Standard (PCI DSS) ist ein vertraglicher Standard des PCI Security Standards Council, getragen von Visa, Mastercard, American Express, Discover und JCB. Kein Gesetz, aber jeder kartenakzeptierende Händler verpflichtet sich über den Acquiring-Vertrag.
Aktuelle Version ist PCI DSS v4.0.1, 2024 veröffentlicht und seit 31.03.2025 in allen Anforderungen verpflichtend. Sie löst v3.2.1 ab und ergänzt rund 50 neue Anforderungen.
Durchsetzung ist praktisch, nicht staatlich: Nicht-konforme Händler zahlen Acquirer-Strafen von 5.000 bis 100.000 EUR pro Monat, erhöhte Transaktionsgebühren und verlieren im Extremfall die Kartenakzeptanz. Nach einem Datenleck multipliziert Nicht-Compliance Klagen, Forensikkosten und Reputationsschaden. In Deutschland überlagert sich das mit BaFin-Aufsicht (bei lizenzierten Zahlungsdienstleistern gemäß ZAG) und DSGVO-Meldepflichten über die Aufsichtsbehörden der Länder.
Die 12 Kernanforderungen von PCI DSS
Organisiert in sechs Zielen:
| Ziel | Anforderung |
|---|---|
| Sicheres Netzwerk aufbauen und erhalten | 1. Netzwerksicherheitskontrollen installieren und warten (Firewalls) |
| 2. Sichere Konfigurationen für alle Systemkomponenten | |
| Karteninhaberdaten schützen | 3. Gespeicherte Karteninhaberdaten schützen (Verschlüsselung, Truncation, Tokenisierung) |
| 4. Übertragung mit starker Kryptografie absichern (TLS 1.2+) | |
| Schwachstellen-Managementprogramm | 5. Schutz vor Malware, regelmäßige Updates |
| 6. Sichere Entwicklung und Pflege von Systemen und Anwendungen | |
| Starke Zugriffskontrollen | 7. Zugriff auf Karteninhaberdaten nach Need-to-know |
| 8. Authentifizierung (MFA verpflichtend) | |
| 9. Physischer Zugriffsschutz | |
| Netzwerke überwachen und testen | 10. Loggen und Überwachen aller Zugriffe |
| 11. Regelmäßige Sicherheitstests (ASV-Scans, Pentests) | |
| Informationssicherheitsrichtlinie pflegen | 12. Richtlinie erstellen und jährlich aktualisieren |
v4.0.1 ergänzt zielgerichtete Risikoanalysen, den "Customized Approach", strengere Authentifizierung (MFA für jeden CDE-Zugang) und ein explizites Skript-Integritätsmonitoring auf Zahlungsseiten gegen Magecart-Angriffe (Requirement 6.4.3).
Merchant-Level von 1 bis 4
PCI-Levels werden je Kartennetz nach Transaktionsvolumen festgelegt. Visa-Definitionen (andere sehr ähnlich):
| Level | Volumen | Validierung |
|---|---|---|
| 1 | > 6 Mio. Kartentransaktionen/Jahr oder Händler nach Datenleck | Jährliches Vor-Ort-Audit durch einen QSA, quartalsweise ASV-Scans |
| 2 | 1 Mio. bis 6 Mio. | Jährliches SAQ (oder QSA-Audit), quartalsweise ASV-Scans |
| 3 | 20.000 bis 1 Mio. E-Commerce | Jährliches SAQ, quartalsweise ASV-Scans |
| 4 | < 20.000 E-Commerce oder < 1 Mio. kartenpräsent | Jährliches SAQ, Scans nach Vorgabe des Acquirers |
Ein Datenleck hebt jeden Händler unabhängig vom Volumen auf Level 1. Service-Provider (Payment-Gateways in der Regel) werden zweistufig klassifiziert, ab 300.000 Transaktionen pro Jahr gelten sie als Level-1-Service-Provider.
SAQ-Typen: Das Dokument, das am meisten zählt
Für Level 2 bis 4 wird Compliance über einen Self-Assessment Questionnaire (SAQ) dokumentiert. Die Varianten unterscheiden sich drastisch in Länge und Kostenaufwand:
| SAQ | Gilt für | Fragen (ca.) |
|---|---|---|
| A | E-Commerce-Händler mit vollständigem Outsourcing an einen PCI-konformen Dritten (Redirect oder Hosted Fields) | ca. 24 |
| A-EP | E-Commerce-Händler, deren Website die Transaktionssicherheit beeinflusst, ohne Kartendaten zu berühren | ca. 191 |
| B | Händler mit Imprintern oder Einzel-Wählverbindungs-Terminals | ca. 41 |
| B-IP | Händler mit IP-verbundenen PTS-Terminals | ca. 86 |
| C-VT | Virtuelle Terminals mit manueller Eingabe | ca. 80 |
| C | Händler mit internet-verbundenen Payment-Anwendungen, kein E-Commerce | ca. 152 |
| P2PE | Händler mit validierter P2PE-Lösung | ca. 35 |
| D | Alles andere. Der Catch-all. Hier landen gespeicherte Kartendaten. | ca. 329 |
Das architektonische Ziel ist fast ausschließlich, in SAQ-A oder A-EP zu landen und dort zu bleiben. Der Sprung von SAQ-A (24 Fragen) zu SAQ-D (329 Fragen) bedeutet rund den zehnfachen Compliance-Aufwand.
Wie der Gateway-Typ Ihren PCI-Scope verändert
Der Scope folgt dem Datenfluss:
- Hosted Gateway (Redirect). Kartendaten berühren Ihre Systeme nie. SAQ-A. Einfachster Fall.
- API-Gateway mit Hosted Fields oder Drop-in-SDK. Daten fließen vom Browser direkt zum Gateway, ohne Ihren Server. SAQ-A, weil Ihre Seite für die Daten selbst als "out of scope" gilt.
- API-Gateway mit server-seitigem Capture. Kartendaten fließen durch Ihren Server. Voller SAQ-D. In modernen Projekten fast immer ein Architektur-Fehler.
- Self-Hosted Gateway. Kartendaten fließen durch Ihren Server und werden unter Umständen gespeichert. Voller SAQ-D. Teuer zu betreiben.
- Krypto-Payment-Gateway. Keine Kartendaten. Kein PCI-Scope.
Für die meisten neuen Integrationen in DACH ist die richtige Wahl ein API-Gateway mit Hosted Fields. SAQ-A plus native UX. Jeder andere Weg tauscht Compliance-Kosten um Größenordnungen teurer ein, als er UX-Gewinn bringt.
Typische Scope-Fallen im deutschen Mittelstand
Händler sprengen regelmäßig ihren PCI-Scope, ohne es zu merken. Besonders häufig in DACH-Setups:
Requirement 6.4.3 ist die größte Änderung in v4.0.1, die deutsche Shops 2026 umsetzen müssen.
Krypto-Gateways und PCI-Scope
Aus Compliance-Kosten-Sicht werden Krypto-Gateways besonders interessant. Ein Krypto-Gateway verarbeitet keine Karteninhaberdaten, nie. Keine PAN, kein CVV, keine Ablaufangaben, kein Issuer, kein Kartennetz. Daraus folgt:
- Ein Händler, der ausschließlich Krypto akzeptiert, hat keinen PCI-DSS-Scope. Kein Fragebogen, keine Scans, kein QSA.
- Ein Händler mit Karten- und Krypto-Akzeptanz behält den PCI-Scope auf der Kartenseite, die Krypto-Spur erhöht ihn nicht.
- Fiat-zu-Krypto-On-Ramp-Flows (Kartenzahlung, Konversion in Krypto) haben PCI-Scope auf der Fiat-Seite, der typischerweise vom Gateway über SAQ-A-EP oder einen QSA-Audit abgedeckt wird.
Für ein reines Krypto-Geschäft ist die Ersparnis real: 20.000 bis 200.000 EUR pro Jahr PCI-Overhead fallen nicht an. Für einen Mixed-Stack erhöht Krypto den PCI-Aufwand nicht.
Das ist einer der leiseren Gründe, warum Krypto-Rails für Digitalgüter, iGaming, Forex und andere volumenstarke Branchen in DACH attraktiv sind. Weniger auditable Oberfläche, weniger Angriffsfläche, weniger Papier. Für lizenzierte Zahlungsdienstleister schließt sich zusätzlich der DORA-Rahmen (seit 17.01.2025) an, der IKT-Resilienz und Drittparteien-Management verbindlich regelt.
Praktische PCI-Compliance-Checkliste 2026
- Merchant-Level klären. Acquirer fragen, wenn unklar.
- SAQ kennen. Architektur auf SAQ-A oder A-EP ausrichten.
- API-Gateway mit Hosted Fields einsetzen. SAQ-A ohne UX-Kompromiss.
- Client-seitige Skripte auf Zahlungsseiten inventarisieren. Jedes Skript dokumentieren, Änderungen monitoren, Überflüssiges entfernen.
- MFA erzwingen für jeden Zugriff auf Systeme mit Kartendaten. Unter v4.0.1 verpflichtend.
- Quartalsweise ASV-Scans. Externe Netzwerk-Scans durch einen Approved Scanning Vendor.
- Jährliche Penetrationstests. Pflicht für Level 1 und 2, gute Praxis für alle.
- Incident-Response-Plan pflegen. Jährlich testen, DSGVO-Meldewege integrieren.
- Mitarbeitende jährlich schulen. Requirement 12 ist explizit.
- Vendor-Scope beobachten. Dienstleister müssen PCI-konform sein, Attestation of Compliance (AOC) schriftlich einholen. Bei lizenzierten Zahlungsdienstleistern zusätzlich BaFin-/ZAG- und DORA-Vorgaben verzahnen.
Krypto-Akzeptanz ohne PCI-Overhead.
GatewayCrypto verarbeitet keine Kartendaten, entsprechend fällt für das Krypto-Bein kein SAQ, kein ASV-Scan und kein QSA-Audit an. MiCA-konform, DORA-ready, SEPA- und SEPA-Instant-Auszahlung in EUR.
Scope-freie Zahlungsspur prüfenSteigern Sie Ihr Geschäft durch die Annahme von Krypto-Zahlungen
Los geht's
Häufig gestellte Fragen
PCI DSS ist der Sicherheitsstandard, den jeder kartenakzeptierende Händler einhalten muss, um Karteninhaberdaten zu schützen. 12 Anforderungen zu Netzwerksicherheit, Verschlüsselung, Zugangskontrolle, Monitoring und Richtlinien. Nicht-Compliance riskiert Acquirer-Strafen und im Ernstfall den Verlust der Kartenakzeptanz.
Ja, immer. Der Scope hängt allerdings an der Integrationsart. Hosted Gateways und API-Gateways mit Hosted Fields halten Sie in SAQ-A (Minimum). Self-Hosted-Integrationen landen in SAQ-D (Maximum).
SAQ-A ist der kürzeste Self-Assessment-Fragebogen (ca. 24 Fragen). Er gilt für E-Commerce-Händler, die Karteninhaberdaten vollständig an einen PCI-konformen Dritten auslagern, typischerweise per Redirect oder Hosted Fields.
Ja. v4.0.1 ist seit 31.03.2025 in allen Kontrollen verpflichtend und ersetzt v3.2.1. Jede Validierung 2026 erfolgt gegen v4.0.1.
Für SAQ-A-Händler einige hundert bis wenige tausend Euro jährlich (SAQ plus ASV-Scans). Für SAQ-D in der Regel 20.000 bis 200.000 EUR pro Jahr, abhängig von der Umgebungskomplexität, inklusive QSA-Honorare bei Level 1.
Nein. Krypto-Zahlungen verarbeiten keine Karteninhaberdaten, entsprechend greift PCI DSS auf der Krypto-Spur nicht. Händler, die ausschließlich Krypto akzeptieren, haben keinen PCI-Scope. GwG, MiCA, Travel Rule und DORA ersetzen das Rahmenwerk auf der Krypto-Seite.
Acquirer-Strafen von 5.000 bis 100.000 EUR pro Monat, höhere Transaktionsgebühren und im Ernstfall Verlust der Kartenakzeptanz. Nach einem Datenleck multipliziert Nicht-Compliance Haftung, Forensikkosten und DSGVO-bezogene Bußgeldrisiken.
Ja, deutlich, wenn korrekt implementiert. Tokenisierung ersetzt die PAN durch einen Token, der außerhalb des Gateways wertlos ist, und hält Ihre Systeme damit aus dem Scope für gespeicherte Karteninhaberdaten heraus. Kombiniert mit Hosted Fields für die Erfassung ist das der kürzeste Weg zu SAQ-A.
