PCI-DSS-Grundlagen: Zahlungsdaten sicher verarbeiten

1. Was PCI DSS ist und warum der Scope alles entscheidet

Der Payment Card Industry Data Security Standard (PCI DSS) wird vom PCI Security Standards Council getragen, gegründet von Visa, Mastercard, American Express, Discover und JCB. Er gilt für jeden Merchant, Service Provider oder Payment Processor, der Kartendaten speichert, verarbeitet oder überträgt, unabhängig von Unternehmensgröße oder Umsatz. Zentrale Begriffe sind der PAN (Primary Account Number, die Kartennummer selbst) und SAD (Sensitive Authentication Data, also CVV, PIN und vollständiger Magnetstreifen- beziehungsweise Chip-Inhalt).

Entscheidend ist der Begriff PCI Scope: Jede Systemkomponente, die PAN speichert, verarbeitet oder überträgt, oder die ungeschützt mit einer solchen Komponente verbunden ist, zählt zur Cardholder Data Environment (CDE) und damit zum Prüfumfang. Je kleiner dieser Scope, desto weniger Systeme müssen nach den zwölf PCI-DSS-Hauptanforderungen abgesichert, dokumentiert und jährlich neu bewertet werden. Scope-Reduktion ist deshalb die wichtigste strategische Entscheidung vor jeder Zahlungsintegration, kein nachträgliches Sicherheits-Add-on.

2. Merchant-Level und die vier PCI-DSS-Compliance-Stufen

Die vier Merchant-Level richten sich nach dem jährlichen Transaktionsvolumen und werden von der Acquiring Bank festgelegt, nicht vom Händler selbst. Level 1 (über 6 Millionen Transaktionen pro Jahr oder nach einem Datenschutzvorfall) erfordert einen jährlichen Report on Compliance (ROC) durch einen Qualified Security Assessor (QSA) vor Ort. Level 2 (1 bis 6 Millionen), Level 3 (20.000 bis 1 Million E-Commerce-Transaktionen) und Level 4 (unter 20.000) zertifizieren sich in der Regel selbst über ein Self-Assessment Questionnaire (SAQ).

Für die überwiegende Mehrheit der Magento-Shops in Deutschland gilt Level 4: Self-Assessment statt externem QSA-Audit. Das bedeutet weniger externe Prüfpflicht, aber nicht weniger Verantwortung, die Haftung bei einem Datenverlust bleibt vollständig beim Merchant. Acquirer und Payment Service Provider wie Adyen, Mollie oder Ratepay fordern den jährlichen Nachweis der SAQ-Konformität regelmäßig über ein eigenes Compliance-Portal ein und können bei Nichterfüllung erhöhte Transaktionsgebühren oder eine Kündigung des Merchant-Vertrags veranlassen.

3. SAQ-Typen im Überblick: SAQ A, SAQ A-EP, SAQ D

SAQ A mit rund 22 Anforderungen gilt für Merchants, die die komplette Zahlungsabwicklung an einen PCI-validierten Drittanbieter auslagern: per vollständigem Redirect auf die Zahlungsseite des Anbieters oder per Iframe, das direkt vom Payment Service Provider geladen wird und dessen Inhalt der Merchant nicht beeinflusst. Der eigene Server sieht zu keinem Zeitpunkt PAN, CVV oder sonstige Kartendaten.

SAQ A-EP mit rund 139 Anforderungen betrifft E-Commerce-Merchants, deren eigene Seite zwar kein PAN empfängt, aber den Payment-Flow aktiv beeinflusst, etwa weil eigenes JavaScript die Iframe-Konfiguration zusammenbaut, Formularfelder stylt oder Events aus dem Zahlungswidget verarbeitet. Der deutlich größere Anforderungskatalog erklärt sich durch das Risiko von Skimming-Angriffen wie Magecart, bei denen manipulierter JavaScript-Code auf der eigenen Seite Kartendaten vor der Übergabe an den PSP abgreift.

SAQ D mit rund 300 Anforderungen, praktisch allen zwölf PCI-DSS-Hauptanforderungen, wird Pflicht, sobald ein Merchant PAN selbst speichert, verarbeitet oder überträgt, etwa durch ein eigenes Zahlungsformular ohne Iframe-Isolation. SAQ D deckt Netzwerksegmentierung, Verschlüsselung, kryptografische Schlüsselverwaltung, Logging über zwölf Monate und vieles mehr ab und ist mit erheblichem Dauer- und Kostenaufwand verbunden.

4. Tokenisierung und Hosted Fields: Kartendaten nie berühren

Bei Hosted Fields lädt der Browser die Eingabefelder für Kartennummer, Ablaufdatum und CVV direkt aus einem Iframe, das von der Domain des PSP ausgeliefert wird, etwa *.adyen.com oder js.stripe.com. Die Eingaben verlassen den Iframe niemals in Richtung der Merchant-Seite. Stattdessen erhält die Merchant-Seite ausschließlich ein Ergebnisobjekt per postMessage mit einem opaken Token oder einer Zahlungsreferenz, niemals mit PAN oder CVV im Klartext.

Tokenisierung unterscheidet sich von Verschlüsselung dadurch, dass ein Token keine mathematisch umkehrbare Transformation der Kartennummer ist, sondern lediglich ein Verweis auf einen Datensatz, der ausschließlich beim PSP existiert. Dieser Token kann für Folgezahlungen, Recurring-Abos oder Instant-Purchase-Funktionen wiederverwendet werden, ohne dass die eigentliche Kartennummer jemals erneut übertragen werden muss. Wichtig für die SAQ-Einstufung: Ein Iframe zählt nur dann als vollständig scope-reduzierend, wenn die eigene Seite keinerlei Kontrolle über dessen Inhalt oder Styling per Cross-Origin-Zugriff hat.

<!-- Hyva checkout template: mounts hosted payment fields served from the PSP domain. -->
<!-- This container never receives raw PAN, CVV or expiry values; only a payment -->
<!-- result reference reaches this page via postMessage from the isolated iframe. -->
<div x-data="hostedPaymentFields()" x-init="mount()" class="rounded-xl border border-slate-200 p-4">
    <div id="adyen-dropin-container"></div>
    <p class="text-xs text-slate-500 mt-2" x-show="error" x-text="error"></p>
</div>

<script>
function hostedPaymentFields() {
    return {
        error: null,
        mount() {
            // Adyen Web Components render the actual card fields inside an isolated
            // iframe hosted on adyen.com. Raw card data never touches this origin.
            const checkout = new AdyenCheckout({
                environment: 'live',
                clientKey: window.checkoutConfig.adyenClientKey,
                onPaymentCompleted: (result) => {
                    // Only an opaque result code / payment reference is sent to our backend
                    fetch('/rest/V1/adyen/payments/result', {
                        method: 'POST',
                        headers: { 'Content-Type': 'application/json' },
                        body: JSON.stringify({ resultCode: result.resultCode, ref: result.pspReference })
                    });
                },
                onError: (error) => { this.error = error.message; }
            });
            checkout.create('dropin').mount('#adyen-dropin-container');
        }
    };
}
</script>

5. Magento-Integrationsmuster außerhalb des PCI-Scopes

Magentos Vault-Modul speichert nur PSP-Tokens in der payment_token-Entität, niemals Kartendaten. In Kombination mit dem Payment Gateway Command Pool Pattern lassen sich Authorize-, Capture- und Vault-Befehle sauber trennen: Jede Command-Klasse baut ausschließlich Requests mit Token-Referenzen und Beträgen, nie mit PAN. Die Instant-Purchase-Funktion nutzt gespeicherte Tokens, um wiederkehrenden Kunden einen Checkout ohne erneute Karteneingabe zu ermöglichen, ohne dass Magento selbst jemals Kartendaten im Klartext verarbeitet.

Der HTTP-Client, der die eigentliche API-Kommunikation mit dem PSP übernimmt, sollte strikt gegen versehentliches Logging von sensiblen Feldern abgesichert sein: Request- und Response-Logger dürfen niemals ungefilterte Payloads persistieren, wenn diese potenziell PAN-ähnliche Werte enthalten könnten. Ein sauberes DI-Setup mit dediziertem Command Pool pro Zahlungsart hält die Verantwortlichkeiten klar getrennt und erleichtert spätere Audits erheblich, weil sich der Kartendatenfluss anhand des Codes lückenlos nachvollziehen lässt.

<?php

declare(strict_types=1);

namespace Mironsoft\PaymentGateway\Gateway\Http\Client;

use Magento\Payment\Gateway\Http\ClientInterface;
use Magento\Payment\Gateway\Http\TransferInterface;
use Magento\Payment\Gateway\Http\ClientException;
use Psr\Log\LoggerInterface;

/**
 * Sends authorize/capture requests to the PSP API using only the previously
 * issued vault token. Raw card data (PAN, CVV) is never present in this
 * class, in its request payload, or in any log statement it produces.
 */
final class TokenPaymentClient implements ClientInterface
{
    public function __construct(
        private readonly GatewayHttpClientInterface $httpClient,
        private readonly LoggerInterface $logger
    ) {
    }

    /**
     * Builds and sends the authorize request using an opaque payment token.
     *
     * @param TransferInterface $transferObject
     * @return array
     * @throws ClientException
     */
    public function placeRequest(TransferInterface $transferObject): array
    {
        $request = $transferObject->getBody();

        // Only a vault token reference is transmitted, never PAN or CVV
        $payload = [
            'amount' => $request['amount'],
            'currency' => $request['currency'],
            'paymentToken' => $request['payment_token'], // opaque PSP token
            'merchantReference' => $request['order_increment_id'],
        ];

        try {
            return $this->httpClient->post('/payments/authorise', $payload);
        } catch (\Throwable $e) {
            // Never log $payload here, even the token reference should stay out of plain logs
            $this->logger->critical('Gateway authorize failed: ' . $e->getMessage());
            throw new ClientException(__('Payment authorization failed.'));
        }
    }
}

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <!-- Vault-enabled payment method: stores only the PSP token, never raw card data -->
    <virtualType name="MironsoftGatewayVaultFacade" type="Magento\Payment\Model\Method\Adapter">
        <arguments>
            <argument name="code" xsi:type="const">Mironsoft\PaymentGateway\Model\Ui\ConfigProvider::CODE</argument>
            <argument name="formBlockType" xsi:type="string">Magento\Vault\Block\Form\Vault</argument>
            <argument name="infoBlockType" xsi:type="string">Magento\Vault\Block\Info\Vault</argument>
            <argument name="commandPool" xsi:type="object">MironsoftGatewayCommandPool</argument>
        </arguments>
    </virtualType>

    <virtualType name="MironsoftGatewayCommandPool" type="Magento\Payment\Gateway\Command\CommandPool">
        <arguments>
            <argument name="commands" xsi:type="array">
                <item name="authorize" xsi:type="string">MironsoftGatewayAuthorizeCommand</item>
                <item name="capture" xsi:type="string">MironsoftGatewayCaptureCommand</item>
                <item name="vault_authorize" xsi:type="string">MironsoftGatewayVaultAuthorizeCommand</item>
            </argument>
        </arguments>
    </virtualType>
</config>

6. Warum eigene Kartendaten-Speicherung den Aufwand vervielfacht

Sobald ein Magento-Shop ein eigenes Zahlungsformular ohne Iframe-Isolation betreibt und PAN in der eigenen Datenbank ablegt, fällt der Merchant automatisch unter SAQ D, im schlimmsten Fall unter einen vollständigen ROC. Das bedeutet: verpflichtende Netzwerksegmentierung zwischen CDE und übrigen Systemen, vierteljährliche externe Vulnerability Scans durch einen Approved Scanning Vendor (ASV), jährliche Penetrationstests, kryptografische Schlüsselverwaltung mit Dual Control und Split Knowledge, sowie Logging aller Zugriffe auf Kartendaten über mindestens zwölf Monate mit sofortiger Verfügbarkeit der letzten drei Monate.

Ein oft übersehener Punkt: Das Speichern von SAD (insbesondere CVV) nach der Autorisierung ist unter keinem einzigen SAQ-Typ erlaubt, selbst nicht verschlüsselt, selbst nicht für einen kurzen Zeitraum. Der Kostenunterschied ist erheblich: Während ein SAQ-A-Merchant meist ohne externe Prüfkosten auskommt, bewegen sich die jährlichen Kosten für QSA-Beratung, ASV-Scans und Penetrationstests bei SAQ D schnell im Bereich mehrerer Tausend bis Zehntausend Euro, zusätzlich zum internen Aufwand für Dokumentation und Nachweisführung.

7. Netzwerksegmentierung und CSP als Schutzschicht

Auch ein Shop mit minimalem PCI-Scope profitiert vom Grundprinzip der Netzwerksegmentierung: Systeme, die keinen funktionalen Grund haben, mit der Zahlungsseite zu kommunizieren, sollten technisch daran gehindert werden. Für die Checkout-Seite selbst ist eine strikte Content Security Policy (CSP) die wirksamste Schutzschicht gegen Skimming-Angriffe wie Magecart: Die Direktive frame-src sollte ausschließlich die Domains der eingesetzten PSPs erlauben, script-src sollte keine generischen Drittanbieter-Skripte auf der Zahlungsseite zulassen, und connect-src begrenzt, wohin per fetch oder XMLHttpRequest überhaupt Daten gesendet werden dürfen.

API-Schlüssel und Webhook-Secrets für den Payment Gateway gehören niemals in den Quellcode oder in eine versionierte Konfigurationsdatei. Sie werden ausschließlich über Umgebungsvariablen oder einen Secrets Manager zur Deploy-Zeit injiziert, mit striktem Zugriff nur für die Deploy-Pipeline und den produktiven Container. Ein Leak eines API-Keys ist zwar kein PCI-Scope-Vorfall im engeren Sinne, kann aber Betrug in erheblichem Umfang ermöglichen und muss deshalb mit derselben Sorgfalt behandelt werden wie ein Kartendaten-Vorfall.

# compose.prod.yaml - payment gateway secrets are injected at deploy time,
# never baked into the image and never committed to version control.
services:
  magento-app:
    image: mironsoft/magento:2.4.8-p4
    environment:
      ADYEN_CLIENT_KEY: ${ADYEN_CLIENT_KEY}
    env_file:
      - ./secrets/adyen.env   # git-ignored, populated by the secrets manager
    labels:
      # Documents that this service intentionally never handles raw card data
      - "com.mironsoft.pci-scope=out-of-scope"
      - "com.mironsoft.saq-type=SAQ-A"

8. Vulnerability Scanning und Penetrationstests je nach SAQ

Vierteljährliche externe ASV-Scans (Approved Scanning Vendor) sind für SAQ A-EP und höher verpflichtend, für einen reinen SAQ-A-Merchant ohne internetseitige CDE-Komponente in der Regel nicht erforderlich, da der Anbieter selbst keinen Systembestandteil betreibt, der überhaupt gescannt werden müsste. Interne Scans, jährliche Penetrationstests nach Requirement 11.4 sowie Segmentierungstests, falls eine Netzwerksegmentierung als Scope-Reduktion beansprucht wird, sind spätestens ab SAQ A-EP relevant.

Mit PCI DSS 4.0, seit März 2025 vollständig verpflichtend, kamen zusätzliche Anforderungen hinzu: authentifizierte interne Scans statt unauthentifizierter Netzwerk-Scans, sowie sogenannte Targeted Risk Analyses, mit denen Merchants die Frequenz bestimmter Kontrollen selbst begründen und dokumentieren müssen. Besonders relevant für SAQ A-EP: Requirement 6.4.3 verlangt eine Inventarisierung und Integritätsprüfung aller Skripte, die auf der Zahlungsseite laufen, und Requirement 11.6.1 fordert einen Change- und Tamper-Detection-Mechanismus für den HTTP-Header- und Skript-Inhalt der Checkout-Seite.

9. Häufige Audit-Fehler bei Magento-Shops

In der Praxis scheitern Magento-Shops selten an der Payment-Integration selbst, sondern an Nebenschauplätzen: Debug-Logging, das versehentlich vollständige Request-Payloads inklusive potenzieller Kartendaten in var/log/debug.log schreibt, Staging-Umgebungen, die aus Bequemlichkeit mit einer Kopie der Produktionsdatenbank inklusive echter Bestelldaten befüllt werden, und veraltete Drittanbieter-Extensions auf der Checkout-Seite, die den SAQ-A-Status ungewollt in Richtung SAQ A-EP verschieben, weil sie zusätzliches JavaScript in den Zahlungsflow einschleusen.

Ein weiterer häufiger Fund: Webhook-Endpunkte, die Zahlungsbestätigungen vom PSP entgegennehmen, aber die Signatur der eingehenden Payload nicht prüfen. Ohne Signaturprüfung kann ein Angreifer gefälschte Erfolgsmeldungen senden und Bestellungen als bezahlt markieren lassen, ohne tatsächlich zu zahlen. Jeder Webhook-Handler muss deshalb die vom PSP bereitgestellte HMAC-Signatur konstant-zeit-sicher verifizieren, bevor die Payload überhaupt verarbeitet wird.

<?php

declare(strict_types=1);

namespace Mironsoft\PaymentGateway\Controller\Webhook;

use Magento\Framework\App\Action\HttpPostActionInterface;
use Magento\Framework\App\RequestInterface;
use Magento\Framework\Controller\Result\JsonFactory;

/**
 * Handles inbound payment notification webhooks. The HMAC signature is
 * verified with a constant-time comparison before the payload is trusted
 * or used to change any order state.
 */
final class Notify implements HttpPostActionInterface
{
    public function __construct(
        private readonly RequestInterface $request,
        private readonly JsonFactory $resultJsonFactory,
        private readonly string $webhookHmacKey
    ) {
    }

    /**
     * @return \Magento\Framework\Controller\Result\Json
     */
    public function execute()
    {
        $rawBody = $this->request->getContent();
        $signatureHeader = (string) $this->request->getHeader('X-Gateway-Signature');

        $expectedSignature = hash_hmac('sha256', $rawBody, $this->webhookHmacKey);

        // Constant-time comparison prevents timing side-channel attacks
        if (!hash_equals($expectedSignature, $signatureHeader)) {
            $result = $this->resultJsonFactory->create();
            return $result->setHttpResponseCode(401)->setData(['error' => 'invalid signature']);
        }

        $payload = json_decode($rawBody, true, 512, JSON_THROW_ON_ERROR);
        // Only after signature verification: process the payment result
        // ... update order status based on $payload['status'] and $payload['merchantReference']

        return $this->resultJsonFactory->create()->setData(['received' => true]);
    }
}

10. Zusammenfassung

Die PCI-DSS-Grundlagen für Magento-Shops lassen sich auf ein Prinzip verdichten: Scope-Reduktion ist billiger als Compliance im großen Scope. Hosted Fields und Iframe-Tokenisierung sorgen dafür, dass Kartendaten den eigenen Server niemals erreichen, was den Merchant auf SAQ A mit rund 22 statt SAQ D mit rund 300 Anforderungen reduziert. Eigene JavaScript-Kontrolle über den Zahlungsflow verschiebt den Status auf SAQ A-EP mit deutlich größerem Anforderungskatalog, eigene Kartendaten-Speicherung erzwingt SAQ D mit Netzwerksegmentierung, quartalsweisen Scans und jährlichen Penetrationstests.

Für Magento-Betreiber bedeutet das konkret: Bei der Wahl des Payment Gateways von Anfang an auf Hosted-Fields- oder Redirect-Flows setzen, das Vault-Modul für Tokenisierung nutzen, Webhook-Endpunkte konsequent signaturprüfen und eine strikte Content Security Policy für die Checkout-Seite durchsetzen. Diese Entscheidungen wirken sich nicht nur auf die jährlichen Compliance-Kosten aus, sondern auch auf die Angriffsfläche, die ein Magecart-artiger Skimming-Angriff überhaupt vorfindet.

11. FAQ: PCI-DSS-Grundlagen für Payment Security