Les cookies tiers peuvent être bloqués par des restrictions du navigateur, des paramètres utilisateur, des indicateurs de développeur ou des règles d'entreprise.
Vous devez vous assurer que votre site ou service offre une expérience de qualité à tous vos utilisateurs, que les cookies tiers soient disponibles ou non.
Cette page contient des informations sur les parcours utilisateur courants qui peuvent être affectés lorsque les cookies tiers sont bloqués.
Parcours utilisateurs courants
De nombreux workflows de paiement et d'achat reposent sur des cookies tiers. Le tableau suivant liste certains parcours utilisateur qui peuvent être affectés si les cookies tiers sont désactivés. Il suggère également des API alternatives que les développeurs peuvent utiliser pour éviter les problèmes. Cette liste n'est pas exhaustive et peut être mise à jour à mesure que d'autres solutions Privacy Sandbox seront disponibles.
Tester vos parcours utilisateur liés aux paiements
Pour savoir si vos parcours utilisateur sont affectés par les restrictions concernant les cookies tiers, le mieux est de les parcourir avec l'indicateur de test des cookies tiers activé.
Pour vous assurer que votre site Web fonctionne comme prévu, testez le parcours suivant avec les cookies tiers restreints :
- Paiement multisite : testez les parcours de paiement qui s'appuient sur un fournisseur de paiement tiers (comme Payer avec <example-provider>). Assurez-vous que :
- La redirection s'effectue correctement.
- La passerelle de paiement est chargée correctement.
- Le processus de paiement peut être finalisé sans erreur.
- L'utilisateur est redirigé vers votre site Web comme prévu.
- Tableaux de bord des paiements : vérifiez que les widgets du tableau de bord des transactions fonctionnent comme prévu lorsque les cookies tiers sont limités. Vérifiez que l'utilisateur peut :
- Accédez au tableau de bord.
- Voir tous les paiements comme prévu.
- Naviguer sans erreur entre les différentes sections du tableau de bord (par exemple, l'historique des transactions et les informations de paiement)
- Gérer les modes de paiement : vérifiez que les widgets de gestion des modes de paiement fonctionnent comme prévu. Une fois les cookies tiers bloqués, vérifiez que :
- L'ajout ou la suppression d'un mode de paiement fonctionnent comme prévu.
- Les paiements effectués avec des modes de paiement enregistrés précédemment ne sont pas concernés.
- Détection des fraudes : comparez le fonctionnement de votre solution de détection des fraudes avec et sans cookies tiers.
- Le blocage des cookies tiers introduit-il des étapes supplémentaires, ce qui entraîne des frictions supplémentaires pour les utilisateurs ?
- Peut-il toujours détecter les schémas suspects lorsque les cookies tiers sont bloqués dans le navigateur ?
- Bouton de paiement personnalisé : testez si les boutons de paiement s'affichent correctement lorsque les cookies tiers sont limités.
- L'utilisateur peut-il toujours effectuer des achats même si le bouton personnalisé n'affiche pas son mode de paiement préféré ?
Paiements intersites
Certains fournisseurs de services de paiement peuvent s'appuyer sur des cookies tiers pour permettre aux utilisateurs d'accéder à leur compte sur plusieurs sites de marchands sans avoir à se réauthentifier. Ce parcours utilisateur peut être impacté pour ceux qui choisissent de naviguer sans cookies tiers.
Formulaires de paiement intégrés
Prenons l'exemple des domaines suivants :
payment-provider.examplefournit des services de paiement aux sites marchands et stocke les données de paiement et de session des utilisateurs.merchant.exampleest un site Web qui intègre un formulaire de paiement fourni parpayment-provider.example.
Un utilisateur vient de se connecter à payment-provider.example (par exemple, lors du règlement sur un autre site). L'utilisateur lance le processus de règlement sur merchant.example.
Avec les cookies tiers disponibles, le formulaire de paiement payment-provider.example intégré à merchant.example aurait accès à son propre cookie de session de premier niveau défini sur payment-provider.example dans le contexte de premier niveau.
Toutefois, si les cookies tiers sont bloqués, le contenu intégré n'aura pas accès à ses propres cookies de premier niveau.
Une solution personnalisable avec FedCM
payment-provider.example doit envisager d'implémenter FedCM pour agir en tant que fournisseur d'identité. Cette approche peut être adaptée dans les cas suivants :
payment-provider.exampleest intégré à des sites tiers sans rapport.payment-provider.exampleest intégré à plus de cinq sites associés.
Le principal avantage de FedCM est que l'UI peut fournir aux utilisateurs plus de contexte pour leurs choix. Avec l'autorisation de l'utilisateur, FedCM permet de partager des données personnalisées entre la partie de confiance (merchant.example) et le fournisseur d'identité (payment-provider.example). La partie de confiance peut choisir de prendre en charge un ou plusieurs fournisseurs d'identité, et l'interface utilisateur FedCM ne s'affiche que sous certaines conditions.
Selon les besoins, les développeurs peuvent choisir entre le mode passif pour que l'invite FedCM s'affiche automatiquement lorsque l'utilisateur est connecté au fournisseur d'identité, ou le mode actif, lorsque le processus de connexion doit être déclenché après une action de l'utilisateur, comme un clic sur un bouton de paiement.
FedCM sert également de signal de confiance pour l'API Storage Access (SAA), qui permet à l'élément intégré d'accéder à ses cookies de premier niveau non partitionnés une fois que l'utilisateur a accepté de se connecter avec le fournisseur de l'élément intégré, sans avoir besoin d'une invite utilisateur supplémentaire.
Solution axée sur l'accès au stockage
L'API Storage Access (SAA) est une autre API à prendre en compte.
Avec l'API Storage Access, l'utilisateur est invité à autoriser l'intégration payment-provider.example à accéder à ses propres cookies de premier niveau. Si l'utilisateur autorise l'accès, le formulaire peut s'afficher comme lorsque des cookies tiers sont disponibles.
Comme pour FedCM, l'utilisateur devra approuver la demande sur chaque nouveau site où payment-provider.example est intégré. Consultez la démonstration de SAA pour comprendre le fonctionnement de l'API.
Si la requête SAA par défaut ne répond pas à vos besoins, envisagez d'implémenter FedCM pour une expérience plus personnalisée.
Réduire les frictions pour les utilisateurs sur un petit nombre de sites associés
Si le site du marchand et le fournisseur de paiement appartiennent à la même entreprise, vous pouvez utiliser l'API Related Website Sets (RWS) pour déclarer les relations entre les domaines. Cela peut contribuer à réduire les frictions pour les utilisateurs. Par exemple, si insurance.example et payment-portal-insurance.example se trouvent dans le même ensemble de sites Web associés, payment-portal-insurance.example aura automatiquement accès à ses propres cookies de premier niveau lorsque l'accès au stockage sera demandé dans l'intégration payment-portal-insurance.example.
Autres solutions expérimentales
Une autre API expérimentale qui pourrait être utile dans ce scénario est Partitioned Popins. L'API est actuellement en phase de développement actif.
Avec les pop-ins partitionnées, l'utilisateur peut être invité à saisir ses identifiants pour se connecter à payment-provider.example dans une pop-in ouverte par merchant.example. L'espace de stockage sera partitionné par l'ouvreur merchant.example. Dans ce cas, l'intégration payment-provider.example aura accès aux valeurs de stockage définies dans le pop-in. Avec cette solution, l'utilisateur devra se connecter au fournisseur de services de paiement sur chaque site.
Paiements via un lien de paiement
Certains fournisseurs de services de paiement proposent un service qui génère un lien de paiement, lequel affiche une page de paiement personnalisée pour le site d'un marchand. Un service de liens de paiement et un portail utilisateur pour le fournisseur de paiement sont souvent implémentés sur des domaines différents, par exemple payment-provider.example et payment-link.example.
payment-link.example intègre un formulaire de paiement fourni par payment-provider.example. Il s'agit d'une variante du modèle de formulaire de paiement intégré.
FedCM,
SAA
et
RWS
sont également de bonnes options à envisager dans ce cas.
Tableaux de bord des paiements
Certaines applications affichent des tableaux de bord des transactions à leurs utilisateurs sur plusieurs sites, ce qui leur permet d'avoir une vue centralisée de leurs activités financières. Pour cela, le tableau de bord doit accéder à des données spécifiques aux utilisateurs dans plusieurs domaines.
Prenons l'exemple des domaines suivants :
earnings.examplefournit un tableau de bord des paiements qui peut être intégré à diverses applications Web. Ce service stocke les données sur les revenus des utilisateurs et les informations sur les sessions.catsitting.exampleetdogsitting.examplesont des sites Web distincts qui intègrent tous les deux le tableau de bordearnings.example.
Un utilisateur se connecte à son compte earnings.example. Lorsqu'ils accèdent à catsitting.example ou dogsitting.example, ils peuvent consulter leurs revenus. Le tableau de bord earnings.example intégré s'appuie sur des cookies de premier niveau et affiche les informations personnalisées sur les revenus de l'utilisateur.
Comme dans les autres exemples, l'intégration earnings.example n'aura pas accès à ses cookies de premier niveau si les cookies tiers sont désactivés.
Tableaux de bord propriétaires
Si les trois domaines appartiennent à la même partie, envisagez d'utiliser SAA avec RWS.
Avec l'API Storage Access, earnings.example peut accéder à son cookie de premier niveau avec l'autorisation de l'utilisateur. Si cette partie utilise earnings.example sur quatre domaines ou moins, déclarer des relations entre eux avec RWS peut offrir une expérience utilisateur plus fluide.
Si la même partie intègre le widget sur plus de cinq domaines, elle ne peut pas déclarer de relations entre tous les sites d'intégration et le domaine du widget, car RWS n'accepte qu'un maximum de six sites dans un ensemble (un site principal et cinq sites associés).
Distribution de tableaux de bord à grande échelle
Dans les cas suivants, SAA et RWS peuvent ne pas être la solution optimale :
- Vous distribuez une solution de tableau de bord pour des sites tiers.
- Vous avez plus de cinq sites qui intègrent votre widget de tableau de bord.
Dans ce cas, earnings.example doit envisager d'implémenter FedCM pour agir en tant que fournisseur d'identité. Cela signifie que l'utilisateur devra se connecter à dogsitting.example avec un compte géré par earnings.example.
FedCM propose une UI personnalisable qui peut aider à communiquer clairement à l'utilisateur les informations qui sont partagées. Avec FedCM, dogsitting.example peut demander à earnings.example de partager des autorisations personnalisées, par exemple pour accéder aux données de transaction.
FedCM sert également de signal de confiance pour l'API Storage Access. L'élément intégré earnings.example se verra accorder l'accès au stockage de ses propres cookies de premier niveau sans invite utilisateur supplémentaire lors de l'appel de l'API SAA.
Paramètres du tableau de bord spécifiques à un site
Si les données n'ont pas besoin d'être partagées sur plusieurs sites, envisagez de partitionner vos cookies avec CHIPS. Les CHIPS peuvent être utiles pour stocker des préférences spécifiques à un site, par exemple la mise en page du tableau de bord ou les filtres.
Gérer les modes de paiement
Un autre parcours courant consiste pour l'utilisateur à afficher et à modifier ses modes de paiement dans un élément intégré sans quitter le site hôte.
Prenons l'exemple du flux suivant :
payments.examplefournit un outil de gestion des paiements qui peut être intégré aux sites Web. Ce service stocke les données de paiement et les informations de session des utilisateurs.shop.exampleest un site Web qui intègre l'outilpayments.examplepour permettre aux utilisateurs d'afficher, de modifier ou de choisir les modes de paiement préférés associés à leur compteshop.example.
Les fournisseurs de services de paiement qui implémentent la gestion des modes de paiement doivent également envisager de devenir un fournisseur d'identité avec FedCM. Avec FedCM, l'utilisateur pourra se connecter à la partie de confiance (shop.example) à l'aide du compte géré par le fournisseur d'identité (payments.example).
Avec l'autorisation de l'utilisateur, FedCM permet de partager des données personnalisées entre la partie de confiance et le fournisseur d'identité. Le principal avantage de FedCM est que l'UI peut fournir aux utilisateurs plus de contexte pour leurs choix. Il sert également de signal de confiance pour l'API Storage Access, qui permet à l'intégration d'accéder à ses cookies de premier niveau.
Lorsque les cookies tiers sont désactivés, l'intégration payments.example n'a pas accès à ses cookies de premier niveau. Dans ce cas, SAA peut contribuer à assurer le bon fonctionnement en demandant l'accès au stockage.
Il arrive que les informations définies dans l'intégration n'aient pas besoin d'être partagées sur d'autres sites d'intégration. payments.example peut n'avoir besoin de stocker différentes préférences utilisateur que pour chaque site d'intégration spécifique. Dans ce cas, envisagez de partitionner les cookies à l'aide de CHIPS. Avec CHIPS, le cookie défini dans payments.example intégré à shop.example ne sera pas accessible par payments.example intégré à another-shop.example.
Partitioned Popins est une autre API expérimentale qui peut potentiellement être utilisée dans ce parcours utilisateur.
Lorsque l'utilisateur se connecte à payments.example dans un pop-in ouvert par shop.example, le stockage est partitionné par l'ouvreur, et l'intégration payments.example a accès aux valeurs de stockage définies dans le pop-in. Toutefois, cette approche exige que les utilisateurs saisissent des identifiants pour se connecter au fournisseur de paiement sur chaque site.
Détection de fraudes
Les systèmes d'analyse des risques peuvent analyser les données stockées dans les cookies pour identifier les schémas qui s'écartent de la norme. Par exemple, si un utilisateur modifie soudainement son adresse de livraison et effectue plusieurs achats importants à l'aide d'un nouvel appareil, le score de fraude potentiel peut être augmenté. Les cookies de détection des fraudes sont généralement des cookies tiers, définis sur les sites des marchands par les fournisseurs de services de paiement ou les widgets de services de prévention des fraudes.
Bien que les restrictions concernant les cookies tiers ne devraient pas perturber les systèmes de détection des fraudes, elles peuvent créer des frictions supplémentaires pour les utilisateurs. Si le système ne peut pas vérifier avec certitude qu'un utilisateur est légitime en raison de cookies bloqués, il peut exiger des vérifications supplémentaires, comme la validation de l'identité.
Pour détecter les fraudes lorsque les cookies tiers sont bloqués, envisagez d'intégrer l'API Private State Tokens (PST) à votre solution de détection des fraudes. Avec PST, un fournisseur de services de paiement peut s'enregistrer en tant qu'émetteur de jetons et accorder aux utilisateurs des jetons qui ne dépendent pas des cookies tiers. Ces jetons peuvent ensuite être utilisés sur les sites des marchands pour vérifier si l'utilisateur est fiable. Pour en savoir plus sur l'implémentation, consultez la documentation pour les développeurs PST.
La Privacy Sandbox teste d'autres API anti-fraude.
Bouton de paiement personnalisé
Les boutons de paiement (tels que Payer avec <mode de paiement préféré>) intégrés aux sites marchands s'appuient souvent sur des informations multisites définies par le fournisseur de paiement. Cela permet la personnalisation et les utilisateurs peuvent profiter d'un processus de paiement fluide avec leur mode de paiement préféré. Si les cookies tiers sont bloqués dans le navigateur de l'utilisateur, cela peut avoir un impact sur l'affichage des boutons de paiement personnalisés.
Bien que SAA puisse autoriser l'accès au stockage, l'invite requise peut ne pas offrir une expérience utilisateur idéale.
Nous étudions une solution potentielle qui cible spécifiquement ce cas d'utilisation : Fenced Frames avec accès aux données locales non partitionnées. L'API est actuellement en phase de développement actif. Vous pouvez contribuer à son avenir. Essayez-le vous-même et donnez-nous votre avis.
Aide et commentaires
Si vous avez des questions ou des commentaires sur les parcours utilisateur ou les API décrits dans ce guide, vous pouvez nous les envoyer.