Chrome bietet Nutzern eine neue Möglichkeit, Drittanbieter-Cookies zu aktivieren oder zu deaktivieren. Sie müssen Ihre Website für Nutzer vorbereiten, die ohne Drittanbieter-Cookies surfen möchten.
Auf dieser Seite finden Sie Informationen dazu, was von den bevorstehenden Änderungen betroffen sein könnte.
Häufige Kaufprozesse
Viele Zahlungs- und Einkaufsabläufe basieren auf Drittanbieter-Cookies. In der folgenden Tabelle sind einige User Journeys aufgeführt, die möglicherweise betroffen sind, wenn Drittanbieter-Cookies deaktiviert werden. Außerdem werden alternative APIs vorgeschlagen, mit denen Entwickler Fehler vermeiden können. Diese Liste ist möglicherweise nicht vollständig und wird aktualisiert, sobald weitere Privacy Sandbox-Lösungen verfügbar sind. Bitte teilen Sie uns Ihr Feedback mit, wenn Sie weitere betroffene Szenarien finden.
Zahlungsbezogene User Journeys testen
Am besten testen Sie, ob Ihre Nutzerflüsse von Einschränkungen für Drittanbieter-Cookies betroffen sind, indem Sie sie mit aktiviertem Testflag für Drittanbieter-Cookies durchgehen.
Testen Sie den folgenden Ablauf, um sicherzustellen, dass Ihre Website wie erwartet funktioniert, wenn Drittanbieter-Cookies eingeschränkt sind:
- Websiteübergreifender Bezahlvorgang: Testen Sie die Zahlungsabläufe, die auf einem Zahlungsanbieter von Drittanbietern basieren (z. B. Pay with <example-provider>). Prüfen Sie Folgendes:
- Die Weiterleitung erfolgt erfolgreich.
- Das Zahlungsgateway wird korrekt geladen.
- Der Zahlungsvorgang kann ohne Fehler abgeschlossen werden.
- Der Nutzer wird wie erwartet zu Ihrer Website weitergeleitet.
- Zahlungs-Dashboards: Testen Sie, ob die Widgets im Transaktions-Dashboard wie erwartet funktionieren, wenn Drittanbieter-Cookies eingeschränkt sind. Prüfen Sie, ob der Nutzer Folgendes tun kann:
- Rufen Sie das Dashboard auf.
- Alle Zahlungen werden wie erwartet angezeigt.
- Sie können problemlos zwischen den verschiedenen Bereichen des Dashboards wechseln (z.B. Transaktionsverlauf, Zahlungsdetails).
- Zahlungsmethoden verwalten: Testen Sie, ob die Widgets zur Verwaltung von Zahlungsmethoden wie erwartet funktionieren. Prüfen Sie bei blockierten Drittanbieter-Cookies Folgendes:
- Das Hinzufügen oder Löschen einer Zahlungsmethode funktioniert wie erwartet.
- Zahlungen mit zuvor gespeicherten Zahlungsmethoden sind davon nicht betroffen.
- Betrugserkennung: Vergleichen Sie, wie Ihre Lösung zur Betrugserkennung mit und ohne Drittanbieter-Cookies funktioniert.
- Erfordert das Blockieren von Drittanbieter-Cookies zusätzliche Schritte, die für Nutzer zusätzlichen Aufwand bedeuten?
- Kann der Dienst verdächtige Muster auch erkennen, wenn Drittanbieter-Cookies im Browser blockiert sind?
- Personalisierte Schaltfläche für den Bezahlvorgang: Testen Sie, ob Zahlungsschaltflächen bei eingeschränkten Drittanbieter-Cookies korrekt dargestellt werden.
- Kann der Nutzer weiterhin Käufe abschließen, auch wenn auf der personalisierten Schaltfläche nicht seine bevorzugte Methode angezeigt wird?
Websiteübergreifende Zahlungen
Einige Zahlungsanbieter nutzen möglicherweise Drittanbieter-Cookies, damit Nutzer auf mehrere Händlerwebsites zugreifen können, ohne sich noch einmal authentifizieren zu müssen. Dieser User Journey kann sich für Nutzer ändern, die ohne Drittanbieter-Cookies surfen.
Eingebettete Zahlungsformulare
Betrachten Sie die folgenden Domains:
payment-provider.example
bietet Zahlungsdienste für Händlerwebsites an und speichert Zahlungs- und Sitzungsdaten von Nutzern.merchant.example
ist eine Website, auf der ein vonpayment-provider.example
bereitgestelltes Zahlungsformular eingebettet ist.
Ein Nutzer hat sich gerade bei payment-provider.example
angemeldet, z. B. beim Bezahlen auf einer anderen Website. Der Nutzer startet auf merchant.example
den Bezahlvorgang.
Wenn Drittanbieter-Cookies verfügbar sind, hätte das auf merchant.example
eingebettete payment-provider.example
-Zahlungsformular Zugriff auf ein eigenes Sitzungs-Cookie auf oberster Ebene, das auf payment-provider.example
im Kontext der obersten Ebene festgelegt wurde.
Wenn Drittanbieter-Cookies jedoch blockiert sind, hat das eingebettete Element keinen Zugriff auf seine eigenen Top-Level-Cookies.

Eine anpassbare Lösung mit FedCM
payment-provider.example
sollte FedCM implementieren, um als Identitätsanbieter zu fungieren. Dieser Ansatz kann in folgenden Fällen gut geeignet sein:
payment-provider.example
ist auf nicht zugehörigen Websites von Drittanbietern eingebettet.payment-provider.example
ist auf mehr als fünf ähnlichen Websites eingebettet.
Der Hauptvorteil von FedCM besteht darin, dass die Benutzeroberfläche Nutzern mehr Kontext für ihre Entscheidungen bieten kann. Mit der Nutzerberechtigung ermöglicht FedCM die Freigabe von benutzerdefinierten Daten zwischen der vertrauenden Partei (merchant.example
) und dem Identitätsanbieter (payment-provider.example
). Die vertrauende Partei kann einen oder mehrere Identitätsanbieter unterstützen. Die FedCM-Benutzeroberfläche wird nur unter bestimmten Bedingungen angezeigt.
Je nach Bedarf können Entwickler zwischen dem passiven Modus wählen, bei dem die FedCM-Aufforderung automatisch angezeigt wird, wenn der Nutzer beim Identitätsanbieter angemeldet ist, oder dem aktiven Modus, bei dem der Anmeldevorgang nach einer Aktion des Nutzers ausgelöst werden soll, z. B. nach dem Klicken auf eine Schaltfläche für den Bezahlvorgang.
FedCM dient auch als Vertrauenssignal für die Storage Access API (SAA), sodass das eingebettete Element auf seine nicht partitionierten Top-Level-Cookies zugreifen kann, nachdem der Nutzer zugestimmt hat, sich beim Anbieter des eingebetteten Elements anzumelden, ohne dass eine zusätzliche Nutzeraufforderung erforderlich ist.
Lösung, die sich auf den Speicherzugriff konzentriert
Eine weitere API, die Sie in Betracht ziehen sollten, ist die Storage Access API (SAA).
Bei der SAA wird der Nutzer aufgefordert, das Einbetten von payment-provider.example
zuzulassen, damit es auf seine eigenen Cookies auf oberster Ebene zugreifen kann. Wenn der Nutzer den Zugriff genehmigt, kann das Formular wie bei verfügbaren Drittanbieter-Cookies gerendert werden.
Genau wie bei FedCM muss der Nutzer die Anfrage auf jeder neuen Website genehmigen, auf der payment-provider.example
eingebettet ist. In der SAA-Demo erfahren Sie, wie die API funktioniert.
Wenn der Standard-SAA-Prompt nicht Ihren Anforderungen entspricht, können Sie FedCM implementieren, um die Funktion besser an Ihre Bedürfnisse anzupassen.
Reibungsverluste für Nutzer auf einer kleinen Anzahl ähnlicher Websites reduzieren
Wenn sowohl die Händlerwebsite als auch der Zahlungsanbieter zum selben Unternehmen gehören, können Sie mit der API für zugehörige Website-Sets (Related Website Sets, RWS) Beziehungen zwischen Domains deklarieren. Das kann die Nutzerfreundlichkeit verbessern: Wenn sich insurance.example
und payment-portal-insurance.example
beispielsweise im selben RWS befinden, erhält payment-portal-insurance.example
automatisch Zugriff auf seine eigenen Top-Level-Cookies, wenn der Speicherzugriff innerhalb des payment-portal-insurance.example
-Embeddings angefordert wird.
Andere experimentelle Lösungen
Eine weitere experimentelle API, die in diesem Szenario hilfreich sein könnte, ist die API für partitionierte Pop-ups. Die API befindet sich derzeit in der aktiven Entwicklungsphase.
Bei partitionierten Pop-ups können Nutzer aufgefordert werden, ihre Anmeldedaten einzugeben, um sich in payment-provider.example
in einem Pop-up anzumelden, das von merchant.example
geöffnet wurde. Der Speicher wird vom Öffner merchant.example
partitioniert. In diesem Fall hat die payment-provider.example
-Einbettung Zugriff auf die im Pop-up festgelegten Speicherwerte. Bei dieser Lösung muss sich der Nutzer auf jeder Website beim Zahlungsanbieter anmelden.
Zahlungen über Zahlungslink
Einige Zahlungsanbieter bieten einen Dienst an, mit dem ein Zahlungslink generiert wird, über den eine benutzerdefinierte Zahlungsseite für die Website eines Händlers gerendert wird. Ein Dienst für Zahlungslinks und ein Nutzerportal für den Zahlungsanbieter werden oft in verschiedenen Domains implementiert, z. B. payment-provider.example
und payment-link.example
.
payment-link.example
bettet ein Zahlungsformular von payment-provider.example
ein. Dies ist eine Variante des Musters für das eingebettete Zahlungsformular.
FedCM, SAA und RWS sind auch gute Optionen für diesen Fall.
Dashboards für Zahlungen
Einige Anwendungen zeigen ihren Nutzern Transaktionsdashboards auf mehreren Websites an, um eine zentrale Übersicht über ihre Finanzaktivitäten zu erhalten. Dazu muss das Dashboard auf nutzerspezifische Daten in mehreren Domains zugreifen können.
Betrachten Sie die folgenden Domains:
earnings.example
bietet ein Zahlungsdashboard, das in verschiedene Webanwendungen eingebettet werden kann. In diesem Dienst werden Daten zu den Einnahmen von Nutzern und Sitzungsinformationen gespeichert.catsitting.example
unddogsitting.example
sind separate Websites, auf denen dasearnings.example
-Dashboard eingebettet ist.
Ein Nutzer meldet sich in seinem earnings.example
-Konto an. Wenn sie catsitting.example
oder dogsitting.example
aufrufen, können sie ihre Einnahmen einsehen. Das eingebettete earnings.example
-Dashboard verwendet Top-Level-Cookies und zeigt die personalisierten Einnahmen des Nutzers an.
Wie in anderen Beispielen hat das earnings.example
-Embed keinen Zugriff auf seine Cookies auf oberster Ebene, wenn Drittanbieter-Cookies deaktiviert sind.

Dashboards mit selbst erhobenen Daten
Wenn alle drei Domains derselben Partei gehören, sollten Sie SAA zusammen mit RWS verwenden.
Mit SAA kann earnings.example
mit Nutzerberechtigung auf sein Cookie der obersten Ebene zugreifen. Wenn diese Partei die earnings.example
in vier oder weniger Domains verwendet, kann die Deklarierung von Beziehungen zwischen ihnen mit RWS die Nutzerfreundlichkeit verbessern.
Wenn dieselbe Partei das Widget in mehr als fünf Domains einbettet, kann sie keine Beziehungen zwischen allen Websites, in denen das Widget eingebettet ist, und der Domain des Widgets angeben, da RWS nur bis zu sechs Websites in einem Set unterstützt – eine primäre und fünf verknüpfte Websites.
Verteilung skalierter Dashboards
In den folgenden Fällen sind SAA und RWS möglicherweise nicht die optimale Lösung:
- Sie vertreiben eine Dashboard-Lösung für Websites von Drittanbietern.
- Ihr Dashboard-Widget ist auf mehr als fünf Websites eingebettet.
In diesem Fall sollte earnings.example
FedCM implementieren, um als Identitätsanbieter zu fungieren. Das bedeutet, dass sich der Nutzer mit einem von earnings.example
verwalteten Konto bei dogsitting.example
anmelden muss.
FedCM bietet eine anpassbare Benutzeroberfläche, mit der Nutzer klar darüber informiert werden können, welche Informationen weitergegeben werden. Mit FedCM kann dogsitting.example
earnings.example
bitten, benutzerdefinierte Berechtigungen freizugeben, z. B. für den Zugriff auf Transaktionsdaten.
FedCM dient auch als Vertrauenssignal für die Storage Access API. Dem earnings.example
-Embed wird Speicherzugriff auf seine eigenen Top-Level-Cookies gewährt, ohne dass beim SAA API-Aufruf eine zusätzliche Nutzeraufforderung erforderlich ist.
Websitespezifische Dashboard-Einstellungen
Wenn die Daten nicht für mehrere Websites freigegeben werden müssen, können Sie Ihre Cookies mit CHIPS partitionieren. CHIPS können nützlich sein, um standortspezifische Einstellungen zu speichern, z. B. das Dashboard-Layout oder Filter.
Zahlungsmethoden verwalten
Eine weitere gängige Vorgehensweise ist, dass Nutzer ihre Zahlungsmethoden in einem eingebetteten Element ansehen und bearbeiten können, ohne die Hostwebsite zu verlassen.
Betrachten Sie den folgenden Ablauf:
payments.example
bietet ein Zahlungsverwaltungstool, das in Websites eingebettet werden kann. In diesem Dienst werden Zahlungsdaten und Sitzungsinformationen von Nutzern gespeichert.shop.example
ist eine Website, auf der daspayments.example
-Tool eingebettet ist. So können Nutzer die mit ihremshop.example
-Konto verknüpften bevorzugten Zahlungsmethoden ansehen, bearbeiten oder auswählen.
Zahlungsdienstleister, die die Verwaltung von Zahlungsmethoden implementieren, sollten auch die Möglichkeit in Betracht ziehen, sich als Identitätsanbieter mit FedCM zu registrieren. Mit FedCM kann sich der Nutzer über das vom Identitätsanbieter (payments.example
) verwaltete Konto bei der vertrauenden Partei (shop.example
) anmelden.
Mit der Nutzerberechtigung ermöglicht FedCM die Freigabe benutzerdefinierter Daten zwischen der vertrauenden Partei und dem Identitätsanbieter. Der Hauptvorteil der Verwendung von FedCM besteht darin, dass die Benutzeroberfläche Nutzern mehr Kontext für ihre Entscheidungen bieten kann. Außerdem dient es als Vertrauenssignal für die Storage Access API, wodurch das eingebettete Element auf seine Cookies der obersten Ebene zugreifen kann.
Wenn Drittanbieter-Cookies deaktiviert sind, hat das payments.example
-Embed keinen Zugriff auf seine Cookies auf oberster Ebene. In diesem Fall kann SAA dazu beitragen, den ordnungsgemäßen Betrieb zu gewährleisten, indem der Speicherzugriff angefordert wird.
Manchmal müssen die im Embed festgelegten Informationen nicht für andere Websites freigegeben werden. payments.example
muss möglicherweise nur unterschiedliche Nutzereinstellungen für jede einzelne Website speichern, auf der Inhalte eingebettet werden. In diesem Fall sollten Sie Cookies mit CHIPS partitionieren. Mit CHIPS kann das Cookie, das in payments.example
auf shop.example
gesetzt wurde, nicht von payments.example
auf another-shop.example
abgerufen werden.
Eine weitere experimentelle API, die in diesem Nutzerfluss verwendet werden kann, ist die API für unterteilte Pop-ups.
Wenn sich der Nutzer in payments.example
in einem Pop-up anmeldet, das von shop.example
geöffnet wurde, wird der Speicherplatz vom Öffner partitioniert und das payments.example
-Embed hat Zugriff auf die Speicherwerte, die im Pop-up festgelegt wurden. Bei diesem Ansatz müssen Nutzer jedoch auf jeder Website Anmeldedaten eingeben, um sich beim Zahlungsanbieter anzumelden.
Betrugserkennung
Risikoanalysesysteme können die in Cookies gespeicherten Daten analysieren, um Muster zu identifizieren, die von der Norm abweichen. Wenn ein Nutzer beispielsweise plötzlich seine Versandadresse ändert und mehrere große Käufe mit einem neuen Gerät tätigt, kann der Wert für potenziellen Betrug erhöht werden. Cookies zur Betrugserkennung sind in der Regel Drittanbieter-Cookies, die von Zahlungsanbietern oder Widgets von Betrugspräventionsdiensten auf den Händlerwebsites gesetzt werden.
Einschränkungen für Drittanbieter-Cookies sollten die Systeme zur Betrugserkennung nicht beeinträchtigen, können aber zusätzliche Probleme für Nutzer verursachen. Wenn das System aufgrund blockierter Cookies nicht sicher feststellen kann, ob ein Nutzer legitim ist, sind möglicherweise zusätzliche Prüfungen erforderlich, z. B. die Bestätigung der Identität.
Wenn Sie die Betrugserkennung auch dann unterstützen möchten, wenn Drittanbieter-Cookies blockiert sind, sollten Sie die Private State Tokens API in Ihre Betrugserkennungslösung einbinden. Mit PST kann sich ein Zahlungsanbieter als Tokenaussteller registrieren und Nutzern Tokens gewähren, die nicht auf Drittanbieter-Cookies basieren. Diese Tokens können dann auf Händlerwebsites eingelöst werden, um zu prüfen, ob der Nutzer vertrauenswürdig ist. Weitere Informationen zur Implementierung finden Sie in der PST-Entwicklerdokumentation.
Im Rahmen der Privacy Sandbox werden auch andere APIs zur Betrugsprävention getestet.
Personalisierte Schaltfläche für den Bezahlvorgang
Auf Händlerwebsites eingebettete Zahlungsschaltflächen (z. B. Mit <bevorzugte Zahlungsmethode> bezahlen) basieren häufig auf websiteübergreifenden Informationen, die vom Zahlungsanbieter festgelegt wurden. Dies ermöglicht eine Personalisierung und die Nutzer können mit ihrer bevorzugten Zahlungsmethode ganz einfach bezahlen. Wenn Drittanbieter-Cookies im Browser des Nutzers blockiert sind, kann sich das auf das Rendern der personalisierten Zahlungsschaltfläche auswirken.
SAA könnte zwar den Speicherzugriff ermöglichen, die erforderliche Aufforderung führt jedoch möglicherweise nicht zu einer optimalen Nutzererfahrung.
Wir arbeiten an einer potenziellen Lösung, die speziell auf diesen Anwendungsfall ausgerichtet ist: Begrenzte Frames mit lokalem, nicht partitioniertem Datenzugriff. Die API befindet sich derzeit in der aktiven Entwicklungsphase und Sie können ihre Zukunft mitgestalten. Probieren Sie es selbst aus und geben Sie Feedback.
Hilfe
Melden Sie alle Probleme unter goo.gle/report-3pc-broken. Sie können auch ein Feedbackformular einreichen oder ein Problem auf GitHub im Privacy Sandbox-Repository für Entwicklersupport melden.