PCI-DSS-Konformität für E-Commerce: Zahlungssicherheit und Tokenisierung

Die Verluste durch Kartenzahlungsbetrug beliefen sich im Jahr 2025 weltweit auf über 33 Milliarden US-Dollar, und der E-Commerce ist für 73 % aller Kartenbetrugsfälle verantwortlich. Um dem entgegenzuwirken, gibt es den Payment Card Industry Data Security Standard (PCI-DSS), und Version 4.0 – die im März 2025 verbindlich wurde – führte bedeutende neue Anforderungen ein, deren Umsetzung viele E-Commerce-Unternehmen noch immer mit Mühe und Mühe bewältigen.

Die gute Nachricht: Wenn Sie eine gehostete Zahlungslösung wie Shopify Payments oder Stripe Checkout nutzen, wird Ihr PCI-Umfang drastisch reduziert. Die schlechte Nachricht: Es ist nie Null. Jedes E-Commerce-Unternehmen, das Kartenzahlungen akzeptiert, unterliegt PCI-DSS-Verpflichtungen, auch wenn es nie eine Kartennummer sieht.

Wichtige Erkenntnisse

– PCI-DSS v4.0 führt maßgeschneiderte Validierungsansätze und obligatorische MFA für den gesamten Zugriff auf Karteninhaberdaten ein

• Durch die Tokenisierung werden 80–90 % des PCI-Umfangs eliminiert, indem Kartennummern durch nicht umkehrbare Token ersetzt werden – Die Auswahl des SAQ bestimmt Ihren Compliance-Aufwand – die Wahl des richtigen SAQ spart Monate an Arbeit
• Vierteljährliche ASV-Scans und jährliche Penetrationstests sind nicht verhandelbare Anforderungen

---

PCI-DSS v4.0: Was sich geändert hat

PCI-DSS v4.0, das 2022 veröffentlicht wurde und seit dem 31. März 2025 vollständig verpflichtend ist, stellt die bedeutendste Aktualisierung des Standards seit über einem Jahrzehnt dar. Die wichtigsten Änderungen betreffen jedes E-Commerce-Unternehmen.

Wichtige Änderungen in Version 4.0

Die Skriptverwaltungsanforderung

Anforderung 6.4.3 hat besondere Auswirkungen auf den E-Commerce: Sie müssen eine Bestandsaufnahme aller Skripte auf Zahlungsseiten führen und einen Mechanismus implementieren, um nicht autorisierte Änderungen zu erkennen. Das bedeutet:

• Jede auf Ihrer Checkout-Seite geladene JavaScript-Datei muss dokumentiert werden – Content Security Policy (CSP)-Header sollten Skriptquellen einschränken
• Subresource Integrity (SRI)-Hashes sollten den Skriptinhalt überprüfen
• Ein Überwachungsmechanismus muss bei nicht autorisierten Skriptänderungen warnen

Diese Anforderung zielt direkt auf Skimming-Angriffe im Magecart-Stil ab, bei denen Angreifer bösartige Skripte in Zahlungsseiten einschleusen, um Kartendaten zu stehlen.

---

Tokenisierung verstehen

Die Tokenisierung ist die wirkungsvollste Technologie zur Reduzierung des PCI-Umfangs. Es ersetzt sensible Kartendaten durch einen nicht sensiblen Token, der bei einem Verstoß keinen ausnutzbaren Wert hat.

So funktioniert die Tokenisierung

1. Der Kunde gibt seine Kartendaten in das vom Zahlungsanbieter gehostete Formular ein (niemals auf Ihrem Server).
2. Der Zahlungsanbieter erstellt einen Token, der die Karte darstellt
3. Ihr System speichert nur das Token (z. B. tok_1MqLkJLkdIwHu7ixUAuBjz5Y)
4. Für spätere Belastungen senden Sie den Token an den Zahlungsanbieter
5. Der Anbieter ordnet den Token wieder den tatsächlichen Kartendaten zu und wickelt die Zahlung ab

Tokenisierung vs. Verschlüsselung

Implementierung mit wichtigen Plattformen

Shopify: Die Tokenisierung wird vollständig von Shopify Payments abgewickelt. Händler berühren niemals Kartendaten. Die PCI-Konformität wird durch die Level-1-Zertifizierung von Shopify abgedeckt. Sie sind für SAQ-A verantwortlich.

Stripe: Verwenden Sie Stripe Elements oder Stripe Checkout, um sicherzustellen, dass Kartendaten direkt an die Server von Stripe gesendet werden. Ihr Backend empfängt immer nur Token. Dies qualifiziert Sie je nach Implementierung für SAQ-A oder SAQ-A-EP.

Benutzerdefinierte Zahlungsintegration mit Odoo: Wenn Sie eine benutzerdefinierte E-Commerce-Lösung auf Odoo erstellen, integrieren Sie sie mit einem PCI-kompatiblen Zahlungsgateway (Stripe, Adyen, Authorize.net) mithilfe der gehosteten Felder oder des Weiterleitungsansatzes. Verarbeiten Sie niemals rohe Kartendaten auf Ihrem Odoo-Server.

---

Leitfaden zur SAQ-Auswahl

Welcher Self-Assessment Questionnaire (SAQ) Sie ausfüllen müssen, hängt davon ab, wie Sie mit Kartendaten umgehen. Die Wahl des richtigen SAQ – und die Gestaltung Ihres Zahlungsflusses, um sich für einen einfacheren SAQ zu qualifizieren – ist die wichtigste PCI-Entscheidung, die Sie treffen werden.

Leitfaden zur Auswahl des SAQ-Typs

Entscheidungsfluss

Leiten Sie Kunden auf eine gehostete Zahlungsseite (Shopify Checkout, Stripe Checkout, PayPal) weiter? Wenn ja, SAQ-A.

Betten Sie das Formular des Zahlungsanbieters auf Ihrer Seite ein (Stripe Elements, Braintree Hosted Fields)? Wenn ja, SAQ-A-EP. Das Formular wird auf Ihrer Seite gehostet, die Kartendaten gehen jedoch direkt an den Anbieter.

Berühren Kartendaten jemals Ihren Server, auch nur vorübergehend? Wenn ja, SAQ-D. Dies ist die vollständige Bewertung und Sie sollten dringend eine Neuarchitektur in Betracht ziehen, um sich stattdessen für SAQ-A oder SAQ-A-EP zu qualifizieren.

Kostenauswirkungen

Die Architekturentscheidung, gehostete Zahlungsformulare zu verwenden, anstatt Kartendaten selbst zu verarbeiten, kann jährlich 50.000 bis 250.000 US-Dollar an Compliance-Kosten einsparen.

---

3D Secure 2.0: Haftungsverlagerung und Betrugsprävention

3D Secure 2.0 (3DS2) fügt Online-Kartentransaktionen eine Authentifizierungsebene hinzu. Bei ordnungsgemäßer Umsetzung wird die Haftung für Betrug vom Händler auf den Kartenaussteller verlagert.

So funktioniert 3DS2

1. Der Kunde leitet die Zahlung auf Ihrer Website ein
2. Ihr Zahlungsanbieter sendet Transaktionsdaten an den Kartenherausgeber
3. Die Risk Engine des Emittenten wertet die Transaktion aus (Gerätefingerabdruck, Transaktionshistorie, Betrag).
4. Reibungsloser Ablauf: Transaktionen mit geringem Risiko werden stillschweigend authentifiziert (keine Kundenaktion erforderlich)
5. Herausforderungsablauf: Transaktionen mit hohem Risiko erfordern eine zusätzliche Authentifizierung (biometrisch, OTP, App-Bestätigung)
6. Das Authentifizierungsergebnis wird zurückgegeben und die Zahlung wird verarbeitet

3DS2-Vorteile

• Haftungsverschiebung: Die Haftung für Betrug geht bei authentifizierten Transaktionen auf die ausstellende Bank über
• Reduzierter Betrug: 3DS2 reduziert die Betrugsraten um 40–60 % im Vergleich zu nicht authentifizierten Transaktionen
• Bessere UX: Reibungslose Authentifizierung bedeutet, dass 85–95 % der Transaktionen keine zusätzliche Kundenaktion erfordern
• Konformität mit gesetzlichen Bestimmungen: PSD2 Strong Customer Authentication (SCA) erfordert 3DS2 für EU-Transaktionen

Überlegungen zur Implementierung

• Aktivieren Sie 3DS2 über Ihren Zahlungsanbieter (Stripe, Adyen und die meisten Anbieter unterstützen es nativ)
• Konfigurieren Sie risikobasierte Authentifizierungsschwellenwerte: Wenden Sie 3DS2 auf Transaktionen mit höherem Risiko an, während Transaktionen mit geringem Wert oder geringem Risiko ausgenommen werden
• Überwachen Sie die Authentifizierungsraten: Wenn zu viele Transaktionen angefochten werden, überprüfen Sie Ihre Risikosignale
• Testen Sie sowohl reibungslose als auch herausfordernde Abläufe gründlich, bevor Sie sie in Betrieb nehmen

---

Schwachstellenscan und Penetrationstests

PCI-DSS erfordert sowohl ein automatisiertes Schwachstellenscanning (vierteljährlich) als auch manuelle Penetrationstests (jährlich) für alle in den Geltungsbereich fallenden Umgebungen.

Vierteljährliche ASV-Scans

Ein Approved Scanning Vendor (ASV) muss vierteljährlich externe Schwachstellenscans durchführen. Anforderungen:

• Scans müssen alle externen IP-Adressen und Domänen im Cardholder Data Environment (CDE) abdecken.
• Alle Schwachstellen mit hohem Schweregrad (CVSS 4.0+) müssen behoben und erneut gescannt werden, bevor der Scan erfolgreich ist
• Berichte über bestandene Scans müssen für Prüfzwecke aufbewahrt werden
• Gängige ASVs: Qualys, Tenable, SecurityMetrics, Trustwave

Jährlicher Penetrationstest

Anforderung 11.4 schreibt jährliche Penetrationstests von Folgendem vor:

• Netzwerksegmentierungskontrollen (falls zur Reduzierung des Umfangs verwendet)
• Außenumfang des CDE
• Interne Systeme innerhalb des CDE
• Testen von Zahlungsanwendungen auf Anwendungsebene

Neu in v4.0: Penetrationstests müssen jetzt explizit überprüfen, ob die Segmentierungskontrollen funktionieren und dass das CDE ordnungsgemäß vom Rest des Netzwerks isoliert ist.

Kontinuierliche Überwachung

Über vierteljährliche und jährliche Tests hinaus legt PCI-DSS v4.0 Wert auf kontinuierliche Überwachung:

• Dateiintegritätsüberwachung (FIM) für kritische Systemdateien und Zahlungsseitenskripte
• Intrusion Detection/Prevention-Systeme (IDS/IPS) an CDE-Netzwerkgrenzen
• Automatisierte Protokollüberprüfung zur Anomalieerkennung (neue v4.0-Anforderung)
• Echtzeitwarnung bei unbefugten Zugriffsversuchen

---

Aufbau einer PCI-konformen E-Commerce-Architektur

Der effektivste Ansatz zur PCI-Konformität besteht darin, den Umfang durch Architekturentscheidungen zu minimieren.

Empfohlene Architektur

Stufe 1: Zahlungsseite (minimaler Umfang). Verwenden Sie gehostete Zahlungsfelder (Stripe Elements, Adyen Drop-in), die in einen Iframe auf Ihrer Checkout-Seite eingebettet sind. Kartendaten fließen direkt vom Browser des Kunden zum Zahlungsanbieter. Ihr Server sieht es nie.

Stufe 2: Anwendungsserver (außerhalb des Geltungsbereichs). Ihre E-Commerce-Anwendung (Shopify, Odoo, benutzerdefiniert) verwaltet die Auftragsverwaltung, den Lagerbestand und die Kundendaten. Die Kommunikation mit dem Zahlungsanbieter erfolgt ausschließlich über Token.

Stufe 3: Datenspeicherung (außerhalb des Geltungsbereichs für Kartendaten). Ihre Datenbank speichert Bestelldetails, Kundeninformationen und Zahlungstokens – jedoch niemals Kartennummern, CVVs oder Ablaufdaten.

Netzwerksegmentierung

Wenn ein Teil Ihrer Infrastruktur Kartendaten verarbeitet, ist die Netzwerksegmentierung von entscheidender Bedeutung:

• Isolieren Sie das CDE in einem separaten Netzwerksegment (VLAN, Subnetz oder VPC).
• Implementieren Sie Firewall-Regeln, die den Datenverkehr zum und vom CDE einschränken
• Überwachen Sie den gesamten Datenverkehr, der die Segmentierungsgrenze überschreitet
• Testen Sie die Segmentierungskontrollen während des Penetrationstests

Umfassende Anleitungen zur Compliance-Architektur, die über PCI-DSS hinausgehen, finden Sie in unserem Enterprise-Compliance-Handbuch.

---

Häufig gestellte Fragen

Benötige ich PCI-Konformität, wenn ich nur auf Shopify verkaufe?

Ja, aber Ihr Umfang ist minimal. Shopify ist ein PCI-DSS Level 1-zertifizierter Dienstleister, was bedeutet, dass Shopify die schwere Arbeit übernimmt. Sie sind jedoch weiterhin dafür verantwortlich, den SAQ-A jährlich auszufüllen und grundlegende Sicherheitspraktiken einzuhalten: sichere Passwörter, MFA in Ihrem Shopify-Adminbereich, keine Speicherung von Kartendaten außerhalb von Shopify und Schulung des Personals zum Thema Sicherheit.

Was passiert, wenn mein vierteljährlicher ASV-Scan fehlschlägt?

Sie haben die Möglichkeit, die identifizierten Schwachstellen zu beheben und einen erneuten Scan anzufordern. Es gibt keine Strafe für einen nicht bestandenen Scan – nur für den Fall, dass der Scan innerhalb des vierteljährlichen Zeitfensters nicht bestanden wird. Wenn Sie jedoch bei Scans regelmäßig durchfallen und die Einhaltung nicht nachweisen können, erhöht Ihre Acquirer-Bank möglicherweise Ihre Bearbeitungsgebühren, verlangt eine strengere Prüfung oder kündigt im Extremfall Ihr Händlerkonto.

Ist PCI-Compliance gesetzlich vorgeschrieben?

PCI-DSS ist keine staatliche Vorschrift, sondern eine vertragliche Anforderung der Kartenmarken (Visa, Mastercard, American Express, Discover, JCB). Die Einhaltung wird durch Ihre Händlervereinbarung mit Ihrer erwerbenden Bank durchgesetzt. Die Nichteinhaltung kann zu Geldstrafen der Kartenmarken (5.000–100.000 US-Dollar/Monat), erhöhten Transaktionsgebühren und einer Haftung für betrügerische Transaktionen führen. Einige Gerichtsbarkeiten (Nevada, Minnesota, Washington) haben Gesetze erlassen, die PCI-DSS-Anforderungen beinhalten.

In welcher Beziehung steht PCI-DSS zur DSGVO?

PCI-DSS und DSGVO überschneiden sich in Bereichen wie Zugangskontrolle, Verschlüsselung und Reaktion auf Vorfälle, haben jedoch unterschiedliche Schwerpunkte. PCI-DSS schützt insbesondere Zahlungskartendaten, während die DSGVO alle personenbezogenen Daten von EU-Bürgern schützt. Eine Zahlungskartennummer ist im Sinne der DSGVO ebenfalls eine personenbezogene Daten, daher müssen Sie beides einhalten. Weitere Informationen zum Zusammenspiel verschiedener Vorschriften finden Sie in unserem Vergleichsleitfaden zum Datenschutz.

---

Was kommt als nächstes?

Die PCI-DSS-Konformität ist für Unternehmen, die Kartenzahlungen akzeptieren, nicht optional. Die gute Nachricht ist, dass moderne Zahlungsplattformen es erheblich einfacher gemacht haben, indem sie die sensibelsten Aspekte der Kartendatenverarbeitung in Ihrem Namen abwickeln. Ihre Aufgabe besteht darin, die richtige Architektur auszuwählen, den entsprechenden SAQ auszufüllen, kontinuierliche Sicherheitspraktiken aufrechtzuerhalten und bei der Weiterentwicklung des Standards auf dem Laufenden zu bleiben.

ECOSIRE unterstützt E-Commerce-Unternehmen von Anfang an beim Aufbau PCI-konformer Zahlungsarchitekturen. Unsere Shopify-Implementierungen nutzen die Level-1-Zertifizierung von Shopify für minimalen PCI-Bereich, und unsere Odoo ERP-Integrationen verwenden tokenisierte Zahlungsflüsse, die Ihre Systeme vom PCI-Bereich fernhalten. Kontaktieren Sie uns für eine Bewertung der Zahlungssicherheit.

---

Veröffentlicht von ECOSIRE – Unterstützung von Unternehmen bei der Skalierung mit KI-gestützten Lösungen in Odoo ERP, Shopify eCommerce und OpenClaw AI.