WooCommerce + Stripe/PayPal: Ist ein Cookie-Consent-Plugin erforderlich?

    Ich betreue eine WordPress-Website mit folgender Konfiguration:

    • WooCommerce
    • WooCommerce PayPal Payments
    • WooCommerce Stripe Gateway
    • Germanized für WooCommerce Pro
    • Shiptastic inkl. DHL-Integration

    Es sind keine separaten Analytics- oder Marketing-Plugins installiert.

    Meine Frage: Ist bei dieser Konfiguration ein Cookie-Consent-Plugin wie Borlabs Cookie rechtlich erforderlich? Insbesondere interessiert mich, ob die von Stripe verwendeten Cookies _stripe_mid und _stripe_sid sowie mögliche Cookies von PayPal eine vorherige Einwilligung erfordern, oder ob sie zur Zahlungsabwicklung bzw. Betrugsprävention als technisch notwendig gelten.

    Hat jemand Erfahrung mit genau dieser Konfiguration und kann auf eine verlässliche Dokumentation oder rechtliche Einschätzung verweisen?

    Danke vorab!
    Raphael

    PS: Mist, hätte doch besser Rechtswissenschaften studieren sollen, bevor ich Webseiten mache. ;)

    • Gerade eben
    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

    Zitat von Raphael

    rechtliche Einschätzung verweisen

    Nein.

    Zitat von Raphael

    Insbesondere interessiert mich,

    Stripe: _stripe_mid und _stripe_sid

    • __stripe_mid (Laufzeit ca. 1 Jahr) und __stripe_sid (ca. 30 Minuten) setzt Stripe.js zur Betrugserkennung (Browser-/Geräteerkennung über Seitenaufrufe hinweg).
    • Stripe selbst beschreibt sie als für Betrugsprävention gedacht. Das ist ein berechtigtes Interesse, aber nicht automatisch “unbedingt erforderlich” im Sinne von § 25 Abs. 2 Nr. 2 TDDDG. Die Ausnahme ist eng auszulegen, und Betrugsprävention des Zahlungsdienstleisters wird von den Aufsichtsbehörden nicht pauschal darunter gefasst.
    • Praktische Einordnung:
      • Auf der Checkout-/Bezahlseite, wenn der Nutzer aktiv zahlen will: Die Argumentation “technisch erforderlich” ist hier vertretbar und weit verbreitet, aber nicht risikofrei. Die Zahlungsabwicklung ist der ausdrücklich gewünschte Dienst, und Betrugsprävention gehört bei Kartenzahlungen faktisch dazu.
      • Auf allen anderen Seiten (Startseite, Blog, Produktseiten): Wenn Stripe.js dort global geladen wird, setzt es die Cookies schon ohne Zahlungsabsicht. Das ist der kritische Punkt. Hier fehlt der Bezug zum gewünschten Dienst, und die Ausnahme greift nicht.
    • Empfehlung: Stripe.js nur auf Seiten laden, auf denen tatsächlich bezahlt wird (bzw. erst beim Klick auf “Bezahlen”). Damit lässt sich die Ausnahme am besten begründen.

    PayPal

    • Beim Klick auf den PayPal-Button wird der Nutzer auf PayPal weitergeleitet bzw. ein PayPal-Overlay/iFrame geladen. Cookies, die PayPal dort setzt, fallen primär in PayPals eigene Verantwortung.
    • Beim Einbinden des PayPal-SDK (js.paypal.com) auf deiner Seite werden Daten (u. a. IP-Adresse) an PayPal übertragen, und PayPal kann Cookies/Fingerprinting zur Betrugsprävention nutzen. Auch hier gilt: Laden nur im Checkout ist deutlich besser vertretbar als seitenweit.
    • Wenn die Zahlungsart erst nach Auswahl durch den Nutzer geladen wird (Zwei-Klick-Lösung), ist die Lage am saubersten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden