Zahlungsanbieter erkannt

Was diese Prüfung macht

Scannt die Seite nach Zahlungsanbieter-Fingerprints — Script-Sources, iframe-Origins, JS-Globals — und meldet, welcher Anbieter (falls einer) das Checkout abwickelt. Informativ. Aber seine Präsenz erhöht die Stakes auf jede andere Sicherheitsprüfung im Audit.

Warum es zählt

Wenn wir einen Zahlungsanbieter erkennen, nimmst du in der Nutzer-Session Kartendaten an. Damit fällst du unter PCI DSS und auf PSD2-Jurisdiktionen unter Strong Customer Authentication. Die folgenden Prüfungen werden Pflicht statt Nice-to-have:

• HTTPS auf deiner Website — PCI DSS 4.2.1 verlangt TLS für jede Seite, die an Kartendatenübertragung beteiligt ist.
• HSTS aktivieren — verhindert die Downgrade-Angriffe, die TLS aus Checkout-Submissions stripen.
• Sichere Cookie-Attribute — Secure; HttpOnly; SameSite=Lax auf Session-Cookies blockiert Token-Diebstahl per XSS und CSRF.
• Clickjacking-Schutz — X-Frame-Options / CSP frame-ancestors verhindern, dass Angreifer:innen dein Checkout in ihrer Domain framen, um Klicks zu stehlen.

Auf einer Marketing-Site sind schwache Security-Header schlechter Stil. Auf einer Site, die Zahlungen annimmt, sind sie ein wartender Datenschutzvorfall und eine Audit-Haftung.

So behebst du es

Diese Prüfung ist informativ, die Aktion hängt also vom Befund ab.

Erkennungs-Heuristiken zur Referenz. MetricSpot fingerprintet:

• Stripe — <script src="https://js.stripe.com/v3/">, window.Stripe, iframes von js.stripe.com.
• PayPal — <script src="https://www.paypal.com/sdk/js">, data-paypal-button, paypal.Buttons.
• Adyen — checkoutshopper-live.adyen.com-Script-Src, window.AdyenCheckout.
• Braintree — js.braintreegateway.com, window.braintree.
• Square — web.squarecdn.com, Square.payments.
• Mollie — js.mollie.com, Mollie(profileId).
• Razorpay — checkout.razorpay.com, window.Razorpay.
• Paddle — cdn.paddle.com, Paddle.Setup.
• Lemonsqueezy — app.lemonsqueezy.com, LemonSqueezy.Setup.

Wähle einen Integrationsmodus, der den PCI-Scope reduziert. Alle großen Anbieter bieten drei Checkout-Integrationen, in Reihenfolge von höchstem zu niedrigstem PCI-Scope:

1. Direct API (rohe Kartendaten an deinen Server gepostet) — PCI DSS SAQ D, ~300 Controls. Meiden, wenn du kein Compliance-Team hast.
2. Embedded Fields (Stripe Elements, Braintree Hosted Fields, Adyen Components) — Kartenfelder sind vom Anbieter geiframed; dein Server berührt die PAN nie. PCI DSS SAQ A-EP, ~140 Controls.
3. Redirect / Hosted Checkout (Stripe Checkout, PayPal Smart Buttons, Paddle, Lemonsqueezy) — Nutzer:innen werden auf eine vom Anbieter gehostete Seite umgeleitet. PCI DSS SAQ A, ~20 Controls.

Für die meisten SaaS- und E-Commerce-Sites ist Hosted Checkout der richtige Default. Paddle und Lemonsqueezy gehen weiter, indem sie als Merchant of Record agieren — sie übernehmen EU-Mehrwertsteuer, US-Sales-Tax und Chargebacks. Du gibst ein paar Prozentpunkte Marge auf und gewinnst Wochen an Compliance-Arbeit zurück.

Strong Customer Authentication (3DS). Wenn du an EU-/UK-Kund:innen verkaufst und Direct API oder Embedded-Integration nutzt, musst du 3D Secure auf Transaktionen triggern, die keine anerkannte Ausnahme haben. Stripe, Adyen und Braintree exponieren alle setup_future_usage / authentication_required-Flags. Teste mit den Issuer-seitigen 3DS-Challenge-Karten in jeder Anbieter-Sandbox vor dem Launch.

Mindest-Security-Header-Set für jede Seite mit Zahlungsanbieter:

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'; ...
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax

Siehe HSTS aktivieren, Clickjacking-Schutz, Referrer-Policy und sichere Cookie-Attribute jeweils im Detail.

Häufig gestellte Fragen

Wir nutzen Stripe Checkout (hosted). Gilt PCI trotzdem?

Ja — aber auf niedrigstem Scope (SAQ A). Du bestätigst jährlich selbst, dass deine Site nur Stripe-kontrollierten Redirect-/iframe-Code enthält, dass deine Server nie Kartendaten sehen und dass die Site über TLS mit aktuellen Cipher ausgeliefert wird. Stripe stellt ein vorausgefülltes SAQ-A-Template. Hosted Checkout entfernt PCI nicht; es schrumpft es auf eine einzelne Seite.

Warum markiert MetricSpot einen Zahlungsanbieter auf einer Seite ohne offensichtliches Checkout?

Zwei häufige Fälle: eine Pricing-Seite, die js.stripe.com für einen “Jetzt kaufen”-Button lädt, oder ein Footer-”Per PayPal spenden”-Widget. Das Skript wird site-weit geladen, obwohl Checkout nur auf einer Route passiert. Trotzdem im Scope — jede Seite, die Payment-SDK-Code lädt, ist für diese Seite im PCI-Scope. Lazy-Load das SDK nur auf der Checkout-Route, um den Scope zu schrumpfen.

Ändern Apple Pay oder Google Pay die Anforderungen?

Sie reduzieren Friction, keine Anforderungen. Apple Pay und Google Pay-Tokens fließen durch deinen bestehenden Anbieter (Stripe, Adyen, Braintree), und dein PCI-Scope bleibt auf der SAQ-Stufe, die dein Integrationsmodus diktiert. SCA ist automatisch erfüllt, weil die Wallet selbst ein starker Authentifizierungsfaktor ist — Visa und Mastercard behandeln sie als delegierte Authentifizierungs-Ausnahme.