PCI-DSS-Umfang im E-Commerce mit Hosted Fields und Tokenisierung reduzieren

Der Umfang sinkt durch Architektur, nicht durch ein Abzeichen

Hosted Payment Fields und Tokenisierung können den PCI-DSS-Umfang eines Onlineshops reduzieren, wenn rohe Kartendaten vom Zahlungsanbieter erfasst und verarbeitet werden, ohne Händler-Server, APIs oder Datenbanken zu durchlaufen. Sie beseitigen den Umfang nicht und zertifizieren keine Integration. Der Händler verantwortet weiterhin Checkout-Seite, Code, Konfiguration, Zugänge, Bestellungen, Integrationen und Lieferantenbeziehungen. Die richtige Frage lautet daher nicht nur, ob der Anbieter compliant ist, sondern welche Personen, Prozesse und Technologien Kontodaten berühren oder den Zahlungsablauf beeinflussen können.

Entscheidend ist der tatsächlich ausgerollte Datenfluss, nicht der Produktname. Ein optisch eingebettetes Feld kann ein isolierter, vom Anbieter ausgelieferter Frame sein oder ein Händlereingabefeld, das die PAN an Händler-Infrastruktur sendet. Nur eine technische Karte und beobachtbare Nachweise unterscheiden diese Varianten. Dieser Leitfaden ist anbieterneutral; die passende Validierungsmethode und der Fragebogen müssen für die konkrete Umgebung mit Acquirer oder QSA abgestimmt werden.

Daten, Grenzen und Kopien vor der Integration erfassen

Primärfluss und Sekundärsysteme verfolgen

Zeichnen Sie den Weg vom Browser zum Anbieter und von dort zu den Händlerdiensten. Dokumentieren Sie an jedem Übergang Code-Ursprung, Zieldomain, Payload, zurückgegebenen Identifikator, Verschlüsselung, Aufbewahrung und Verantwortliche. Berücksichtigen Sie Frontend, Backend, Queues, Webhooks, Betrugsprävention und Support. Kennzeichnen Sie PAN, Ablaufdatum, Karteninhabername, Sicherheitscodes und Tokens getrennt. Diese Daten sind nicht gleichwertig und dürfen nicht hinter der pauschalen Bezeichnung „Zahlungsdaten“ verschwinden.

Erweitern Sie das Inventar auf Anwendungslogs, APM, Session Replay, Analytics, Crashberichte, Data Lakes, Tickets, E-Mail und Backups. Ein Fehlerhandler, der den Request Body serialisiert, oder ein Werkzeug, das das DOM mitschneidet, kann trotz sauberer Hauptdatenbank unerwartete Kopien anlegen. Suchen Sie auch nach manuellen Exporten, Screenshots und Debug-Variablen. Definieren Sie pro System einen Negativnachweis: Redaction-Konfiguration, geprüfte Logstichprobe, Suchabfrage und verantwortliche Person.

Checkout-Modelle vergleichen, ohne sie gleichzusetzen

Erlebnissteuerung und technische Angriffsfläche

Ein Redirect oder vollständig gehosteter Checkout führt den Käufer auf eine Anbieterseite und schafft meist die klarste Grenze. Ein eingebetteter Hosted Checkout hält mehr vom Ablauf auf der Händlerseite. Hosted Fields platzieren einzelne isolierte Eingaben oder Komponenten in einer vom Händler kontrollierten Seite. Das bietet Layoutkontrolle, lässt die Verantwortung für die Containerseite aber beim Händler. Bei Raw Collection laufen Kartendaten durch Händlercode oder Server, wodurch sich beteiligte Systeme, Personen und Kontrollen deutlich vermehren.

• Redirect: klare Grenze, sichtbarer Wechsel und Abhängigkeit vom Rückweg.
• Hosted Checkout: vom Anbieter verwaltetes Erlebnis, eigenständig oder eingebettet.
• Hosted Fields: vom Anbieter ausgelieferte sensible Eingaben in einer Händlerseite.
• Raw Collection: PAN oder Authentifizierungsdaten gelangen in Händlercode oder Infrastruktur.

Leiten Sie SAQ A nicht automatisch aus einem Produktnamen ab. Seit dem 1. April 2025 unterscheidet das vom PCI SSC erläuterte überarbeitete Kriterium Seiten mit eingebetteten Zahlungsformularen, bei denen der Händler den Schutz vor Skriptangriffen bestätigen muss, von Redirects oder vollständig ausgelagerten Zahlungsfunktionen, für die dieses konkrete Kriterium nicht gilt. Das ist eine Unterscheidung der Teilnahmevoraussetzungen, keine umfassende Garantie.

Den Browser-Anbieter-Token-Fluss gestalten

Rohe Kartendaten dürfen den Händler-Server nicht erreichen

Das Backend erstellt eine Zahlungssitzung mit Betrag und Währung aus der serverseitig berechneten Bestellung und liefert dem Browser nur begrenzte Initialisierungsdaten. Der Browser lädt die Komponente von offizieller Domain und Bibliothek des Anbieters. Der Käufer gibt Daten in die Hosted Fields ein; die Komponente sendet sie direkt an den Anbieter. Dieser liefert Token, Zahlungsmethodenkennung oder Sitzungsreferenz zurück. Der Browser übermittelt dem Backend diese Referenz, niemals PAN oder Sicherheitscode.

Konkrete Implementierungen unterscheiden sich. Stripe dokumentiert, dass Elements sensible Zahlungsdaten in der Komponente tokenisiert, ohne dass sie den Händler-Server berühren. Adyen beschreibt clientseitige Komponenten und einen Vault, in dem ein Token die beim Anbieter gespeicherten Zahlungsdaten repräsentiert. Das sind anbieterspezifische Beispiele, keine universelle Token-Semantik. Format, Lebensdauer, Wiederverwendung, Händlerbindung und Berechtigungen müssen dem Vertrag der gewählten Integration entnommen werden.

Bestellung und Ergebnis serverseitig autoritativ halten

Tokenisierung schützt nicht die Geschäftslogik

Der Client darf Preis, Rabatt, Währung, Versand oder Menge nicht bestimmen. Vor der Zahlungsinitialisierung lädt der Server Katalog- und Warenkorbdaten aus vertrauenswürdigen Quellen, wendet Geschäftsregeln an und berechnet die Summe. Speichern Sie Bestellung, Berechnungsversion, erwarteten Betrag, Währung und Anbieterkennung. Sendet der Browser einen Betrag, behandeln Sie ihn als nicht vertrauenswürdigen Kontext und nicht als Buchungsgrundlage.

Führen Sie nach der Zahlung nicht allein aufgrund der Rückkehrseite aus. Prüfen Sie den Status über Anbieter-API oder authentifizierte Server-zu-Server-Nachricht, gleichen Sie Bestellung, Betrag und Währung ab und machen Sie den Wechsel zu bezahlt idempotent. Verarbeiten Sie doppelte, späte und ungeordnete Callbacks. Ein gültiges Token zeigt nur, dass eine Referenz in ihrem definierten Kontext nutzbar sein kann; es belegt weder die Richtigkeit der Bestellung noch einen endgültigen Zahlungserfolg.

PAN und Authentifizierungsdaten aus Sekundärsystemen halten

Formulieren Sie eine eindeutige Regel: Händler-Backends, Datenbanken, Logs, Analytics, APM, Tickets, E-Mails und Backups dürfen keine vollständige PAN oder sensiblen Authentifizierungsdaten empfangen. Kopieren Sie keinen Feldinhalt aus dem DOM, senden Sie keine vollständigen Fehler an Drittanbieter-Telemetrie und hängen Sie Zahlungswerte nicht an Analytics-Ereignisse. Betriebsoberflächen zeigen nur notwendige und erlaubte Attribute, etwa die vom Anbieter gemeldete Marke, gegebenenfalls letzte Ziffern und eine Transaktionsreferenz.

Ein Token reduziert die Exposition, weil es einen sensiblen Wert im Anwendungsfluss ersetzt. Es ist jedoch weder anonym noch generell harmlos. Es kann mit Kunde, Bestellung oder Zahlungsmethode verknüpft bleiben und innerhalb definierter Berechtigungen Operationen erlauben. Schützen Sie Tokens mit Zugriffskontrolle, Umgebungstrennung, erforderlicher Verschlüsselung, begrenzter Aufbewahrung und Logs ohne Geheimnisse. Verwenden Sie sie nicht als vorhersehbare öffentliche Kennungen.

Skripte und geteilte Verantwortung kontrollieren

Die Host-Seite bleibt eine Händler-Angriffsfläche

Eine isolierte Komponente kann verhindern, dass Händlercode den Feldinhalt direkt liest. Schadcode kann jedoch die Seite verändern, die Komponente austauschen oder Käufer umleiten. Pflegen Sie Skriptinventar und Freigaben, aktualisieren Sie Abhängigkeiten, kontrollieren Sie Änderungen und überwachen Sie Integrität. Nutzen Sie für Nonces, Direktiven und stufenweise Durchsetzung unseren Leitfaden zur Content Security Policy im E-Commerce-Checkout, statt die gesamte Konfiguration hier zu wiederholen.

Erstellen Sie ein Nachweispaket zur Verantwortung: freigegebene Integration, umgesetzte Anbieteranweisungen, erforderliche Anbieterbestätigung, erlaubte Domains und Versionen, Datenflussmatrix, Zugriffsprüfungen, Lognachweise und Testergebnisse. Outsourcing überträgt Funktionen, nicht die letzte Verantwortung des Händlers. Prüfen Sie Lieferantendokumentation und Status erneut, benennen Sie interne Verantwortliche und bewahren Sie datierte, versionierte Nachweise auf.

Manipulation, Ausfälle und Datenabfluss testen

Verändern Sie in einer Testumgebung Betrag und Währung, verwenden Sie ein Token einer anderen Bestellung, spielen Sie eine Referenz erneut ab, senden Sie einen unsignierten Callback, duplizieren Sie einen Webhook und fälschen Sie Browser-Rückgabeparameter. Unterbrechen Sie während Tokenisierung und Bestätigung das Netzwerk und simulieren Sie Timeouts sowie Reloads. Prüfen Sie, dass Retries weder doppelte Bestellungen noch doppelte Ausführung erzeugen und ein Ladefehler der Komponente die Zahlung verständlich stoppt, ohne auf rohe Felder auszuweichen.

Testen Sie anschließend Datenabfluss. Suchen Sie in Logs, APM-Traces, Analytics-Ereignissen, Queues, Supporttickets und Backups des Ablaufs nach Testkartenmustern. Kontrollieren Sie Redaction von Fehlern und Payloads, Tokenzugriffe und die Trennung von Test und Produktion. Jedes Ergebnis braucht einen aufbewahrbaren Nachweis, eine verantwortliche Person und eine Korrekturmaßnahme, nicht nur einen Screenshot einer erfolgreichen Zahlung.

Die Grenze messen und ein Runbook pflegen

Beobachten Sie den Anteil der Zahlungen im freigegebenen Fluss, Ladefehler der Komponente, fehlgeschlagene Tokenisierungen, Abweichungen bei Betrag oder Währung, abgelehnte Callbacks, Dubletten, angehaltene Bestellungen und Funde sensibler Daten in Sekundärsystemen. Ergänzen Sie Alter der Anbieterbestätigung, ungeprüfte Checkout-Abhängigkeiten und Zeit bis zum Abschluss von Ausnahmen. Schwellenwerte entstehen aus der eigenen Baseline, nicht aus universellen Benchmarks.

Das Runbook erklärt, wie Checkout deaktiviert, eine bekannte Version wiederhergestellt, Zugangsdaten rotiert, verdächtige Logs isoliert, Ausführung gestoppt und Anbieter, Acquirer sowie interne Verantwortliche kontaktiert werden. Für eine überprüfbare Trennung von Browser, Anbieter und Bestellsystemen entdecken Sie unsere Leistungen für E-Commerce und Systeme. Wenn Sie Flüsse, Nachweise und Verantwortung vor dem Release prüfen möchten, kontaktieren Sie AE Digital Agency; die Entscheidung zu SAQ-Eignung und Compliance-Validierung bleibt beim zuständigen Acquirer oder QSA.