E-Commerce PCI Compliance ist einer der Bereiche, in denen Händler die meisten Bewertungsfehler machen. Viele glauben, dass die Nutzung von Stripe, PayPal oder einem bekannten Zahlungsgateway sie automatisch von allen PCI-DSS-Pflichten befreit. Die Realität ist differenzierter: Die gewählte Integrationsart bestimmt, welches SAQ gilt und wie viele Kontrollen beim Händler verbleiben. Das Verständnis dieser Unterscheidung ermöglicht es, den Compliance-Perimeter durch die Wahl der richtigen Architektur von Anfang an zu minimieren.
E-Commerce-Checkout und PCI DSS: Was bei der Kartenakzeptanz ausgelöst wird
Jeder Online-Shop, der Kartenzahlungen akzeptiert, löst PCI-DSS-Pflichten für den Händler aus. Die Frage ist nicht, ob die Pflichten gelten, sondern welche und in welchem Umfang. Alles hängt davon ab, wie Kartendaten während des Checkouts fließen. Wenn der Browser des Kunden Kartendaten direkt an die Server des Händlers sendet (auch nur für einen Moment), unterliegt der Händler den umfangreichsten Pflichten von SAQ D mit über 200 zu erfüllenden Kontrollen. Wenn hingegen Kartendaten niemals die Server des Händlers berühren, weil das Zahlungsformular vom Anbieter gehostet wird, kann der Händler für das viel einfachere SAQ A qualifizieren.
Es gibt einen Mittelweg, der durch den SAQ A-EP-Ansatz repräsentiert wird: Der Händler verwendet das JavaScript des Anbieters, um Kartendaten direkt im Browser des Kunden zu erfassen, ohne dass die Daten die Server des Händlers passieren. Dies reduziert den Scope gegenüber SAQ D, erfordert aber immer noch mehr Kontrollen als SAQ A, einschließlich der Verwaltung der Webserver-Sicherheit und des JavaScript-Codes auf Checkout-Seiten. Mit PCI DSS v4 hat die Anforderung an Zahlungsseitenskripte die Position von SAQ-A-EP-Händlern weiter verkompliziert.
Integrationsoptionen und deren Einfluss auf das SAQ
Die wichtigsten Integrationsoptionen für einen E-Commerce sind drei, geordnet von der aufwändigsten zur am wenigsten aufwändigen in Bezug auf PCI DSS. Die erste ist der native Checkout: Der Händler entwickelt und verwaltet das Karteneingabeformular intern. Dies erfordert SAQ D mit dem breitesten Compliance-Perimeter. Die zweite Option sind Hosted Fields oder JavaScript-Injektion: Der Anbieter fügt Eingabefelder in die Seite des Händlers ein, die Kartendaten direkt im Browser erfassen und an den Anbieter senden. Dies führt zu SAQ A-EP mit einem mittleren Scope. Die dritte und am wenigsten aufwändige Option ist die Weiterleitung zu einer gehosteten Zahlungsseite: Der Nutzer verlässt die Website des Händlers, um die Zahlung auf einer vom Anbieter gehosteten Seite abzuschließen, und kehrt danach zurück. Diese Architektur ermöglicht SAQ A.
Tokenisierung fügt in jedem Szenario eine zusätzliche Schutzschicht hinzu. Wenn ein zertifizierter Tokenisierungsanbieter die PAN abfängt, bevor sie die Systeme des Händlers erreicht, und einen irreversiblen Token zurückgibt, hält der Händler niemals sensible Kartendaten. Der Token kann frei für zukünftige Nutzung gespeichert werden (Abonnementverlängerungen, wiederkehrende Bestellungen), ohne dass dies zusätzliche Kartendaten-Sicherheitspflichten begründet, da der Token außerhalb des Systems des Anbieters keinen Wert hat.
Wie PCI Proxy EU den PCI-Scope aus Ihrem E-Commerce eliminiert
Mit PCI Proxy EU sieht der Checkout des Händlers niemals Kartendaten. Das Zahlungsformular wird von der zertifizierten PCI DSS Level 1-Infrastruktur von PCI Proxy EU verwaltet, die die PAN abfängt und dem Händler einen Token zurückgibt, bevor sensible Daten die Server des Online-Shops erreichen. Dies bringt den Händler direkt zu SAQ A und eliminiert die Notwendigkeit für vierteljährliche Schwachstellenscans der Server, umfangreiche Penetrationstests, Zertifikatsverwaltung und CDE-spezifische Zugangskontrollrichtlinien.
Der betriebliche Vorteil ist erheblich, auch für Shops, die wiederkehrende Bestellungen oder Abonnements verwalten. Der vom Händler gespeicherte Token kann verwendet werden, um in Zukunft Karten zu belasten, ohne dass der Händler jemals die ursprüngliche PAN kennt. Dieses Szenario, das zuvor in der PCI-DSS-Compliance komplex zu verwalten war, wird mit einem Tokenisierungsanbieter unkompliziert: Der Händler fordert den Anbieter auf, eine Belastung mithilfe des Tokens zu verarbeiten, und der Anbieter verwendet die PAN, die er in seinem zertifizierten Vault hält. Der Händler sieht niemals die sensiblen Daten und behält den SAQ-A-Perimeter in allen Phasen des Kundenlebenszyklus bei.
Häufig gestellte Fragen
Bin ich PCI DSS-konform, wenn ich Stripe oder PayPal verwende?
Es hängt von der Integration ab. Wenn Sie die Weiterleitung zur Stripe- oder PayPal-Checkout-Seite nutzen, ist Ihr Scope auf SAQ A reduziert. Wenn Sie deren APIs oder JavaScript-Elemente mit auf Ihrer Domain gehosteten Formularen verwenden, ist Ihr Scope SAQ A-EP. Wenn Sie die APIs direkt integriert haben und Kartendaten durch Ihren Server leiten, befinden Sie sich in SAQ D. Die Nutzung eines bekannten Gateways bedeutet nicht automatisch Compliance: Die Integrationsarchitektur ist entscheidend.
Reduziert ein gehosteter Zahlungs-iFrame meinen Scope?
Ja, wenn der iFrame von der Domain des Anbieters geladen wird und Kartendaten nicht durch die Server des Händlers passieren. In diesem Fall ist die typische Qualifikation SAQ A. Vorsicht: Wenn der Händler benutzerdefiniertes JavaScript auf derselben Seite wie den iFrame ausführt, das theoretisch auf die Daten zugreifen könnte, kann der PCI Council verlangen, dass der Händler SAQ A-EP statt SAQ A abschließt. Überprüfen Sie immer die korrekte Klassifizierung mit Ihrem Acquirer.
Ich habe einen WooCommerce-Shop: Was muss ich tun?
WooCommerce selbst bestimmt nicht Ihren PCI-Scope: Entscheidend ist, welches Zahlungsgateway Sie verwenden und wie Sie es integriert haben. Wenn Sie eine Weiterleitung zur gehosteten Zahlungsseite Ihres Anbieters nutzen, können Sie SAQ A abschließen. Wenn Sie Plugins verwenden, die Kartendaten direkt im WooCommerce-Checkout erfassen und über API übermitteln, ist Ihr Scope größer. Überprüfen Sie die Dokumentation Ihres Zahlungs-Plugins und wechseln Sie bei Bedarf zu einer gehosteten Formularlösung.
Keine Kartendaten in Ihrem E-Commerce bedeutet SAQ A, vereinfachte Compliance und sicherere Kunden. Entdecken Sie PCI Proxy EU.