Vérifier l'impact des modifications apportées aux cookies tiers sur vos workflows de paiement

Chrome propose une nouvelle expérience pour les choix des utilisateurs concernant les cookies tiers. Vous devez préparer votre site pour les utilisateurs qui choisissent de naviguer sans cookies tiers.

Cette page contient des informations sur les éléments susceptibles d'être affectés par les modifications à venir.

Parcours utilisateurs courants

De nombreux processus de paiement et d'achat reposent sur des cookies tiers. Le tableau suivant liste certains parcours utilisateur susceptibles d'être affectés si les cookies tiers sont désactivés, et suggère d'autres API que les développeurs peuvent utiliser pour éviter les interruptions. Cette liste n'est pas exhaustive et peut être mise à jour à mesure que d'autres solutions de la Privacy Sandbox seront disponibles. Nous vous invitons à nous faire part de vos commentaires si vous rencontrez d'autres scénarios concernés.

Le meilleur moyen de vérifier si vos flux utilisateur sont affectés par les restrictions de cookies tiers est de les examiner avec l'indicateur de test des cookies tiers activé.

Pour vous assurer que votre site Web fonctionne comme prévu, testez le flux suivant avec les cookies tiers limités:

  • Paiement intersites: testez les flux de paiement qui reposent sur un fournisseur de paiement tiers (par exemple, Payer avec <example-provider>). Assurez-vous que :
    • La redirection est effectuée.
    • 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 sur les 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.
    • Tous les paiements s'affichent comme prévu.
    • Naviguer sans erreur entre les différentes sections du tableau de bord (par exemple, l'historique des transactions, les détails du paiement).
  • Gérer les modes de paiement: vérifiez que les widgets de gestion des modes de paiement fonctionnent comme prévu. Lorsque les cookies tiers sont bloqués, vérifiez les points suivants :
    • L'ajout ou la suppression d'un mode de paiement fonctionne comme prévu.
    • Le paiement avec des modes de paiement précédemment enregistrés n'est pas affecté.
  • 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 entraîne-t-il des étapes supplémentaires, ce qui crée des frictions supplémentaires pour les utilisateurs ?
    • Peut-il toujours détecter des schémas suspects lorsque les cookies tiers sont bloqués dans le navigateur ?
  • Bouton de paiement personnalisé: vérifiez 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 sa méthode préférée ?

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 marchands sans avoir à se réauthentifier. Ce parcours utilisateur peut être affecté pour ceux qui choisissent de naviguer sans cookies tiers.

Formulaires de paiement intégrés

Prenons les domaines suivants:

  • payment-provider.example fournit des services de paiement aux sites marchands et stocke les données de paiement et de session des utilisateurs.
  • merchant.example est un site Web qui intègre un formulaire de paiement fourni par payment-provider.example.

Un utilisateur vient de se connecter à payment-provider.example (par exemple, lors du règlement sur un autre site). L'utilisateur lance un processus de paiement 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, l'intégration n'aura pas accès à ses propres cookies de premier niveau.

Le schéma montre une interaction avec le site Web d&#39;un marchand (merchant.example) qui utilise un widget de paiement d&#39;un fournisseur tiers (payment-provider.example). Lorsque les cookies tiers sont bloqués, le widget ne peut pas accéder à son cookie de premier niveau, ce qui peut perturber l&#39;expérience utilisateur.
Lorsque les cookies tiers sont désactivés, le widget "payment-provider.example" n'a pas accès au cookie de session utilisateur défini dans le contexte de niveau supérieur sur "payment-provider.example".

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.example est intégré à des sites tiers sans rapport.
  • payment-provider.example est intégré à plus de cinq sites associés.

L'avantage principal 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 de manière conditionnelle.

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é avec le fournisseur d'identité, ou le mode actif, lorsque le processus de connexion doit être déclenché après une action de l'utilisateur, comme cliquer sur un bouton de paiement.

Le FedCM sert également de signal de confiance pour l'API Storage Access (SAA), ce qui permet à l'intégration d'accéder à ses cookies de niveau supérieur non partitionnés une fois que l'utilisateur accepte de se connecter avec le fournisseur de l'intégration, sans qu'une invite supplémentaire ne soit nécessaire.

Solution axée sur l'accès au stockage

L'API Storage Access (SAA) est une autre API à prendre en compte. Avec SAA, l'utilisateur est invité à autoriser l'intégration payment-provider.example à accéder à ses propres cookies de premier niveau. Si l'utilisateur approuve l'accès, le formulaire peut s'afficher comme il le fait lorsque des cookies tiers sont disponibles.

Tout comme avec FedCM, l'utilisateur devra approuver la demande sur chaque nouveau site où payment-provider.example est intégré. Regardez la démonstration de SAA pour comprendre le fonctionnement de l'API. Si l'invite 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 Ensembles de sites Web associés (RWS) pour déclarer des relations entre les domaines. Cela peut contribuer à réduire les frictions pour l'utilisateur: par exemple, si insurance.example et payment-portal-insurance.example se trouvent dans le même RWS, payment-portal-insurance.example aura automatiquement accès à ses propres cookies de niveau supérieur lorsque l'accès au stockage est demandé dans l'intégration payment-portal-insurance.example.

Autres solutions expérimentales

Une autre API expérimentale qui peut être utile dans ce scénario est Pop-ups partitionnés. L'API est actuellement en cours de développement.

Avec les pop-ups partitionnés, l'utilisateur peut être invité à saisir ses identifiants pour se connecter à payment-provider.example dans un pop-up ouvert 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-up. Avec cette solution, l'utilisateur devra se connecter au fournisseur de services de paiement sur chaque site.

Certains fournisseurs de services de paiement proposent un service qui génère un lien de paiement, qui affiche une page de paiement personnalisée sur le site d'un marchand. Un service de lien de paiement et un portail utilisateur pour le fournisseur de paiement sont souvent implémentés sur différents domaines, 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 Payments

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 aux données spécifiques à l'utilisateur dans plusieurs domaines.

Prenons les domaines suivants:

  • earnings.example fournit un tableau de bord des paiements pouvant être intégré à diverses applications Web. Ce service stocke les données sur les revenus des utilisateurs et les informations sur les sessions.
  • catsitting.example et dogsitting.example sont des sites Web distincts qui intègrent tous les deux le tableau de bord earnings.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 d'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.

Diagramme illustrant un scénario dans lequel les informations sur les revenus d&#39;un utilisateur, hébergées sur earnings.example, sont affichées dans un tableau de bord intégré sur dogsitting.example.  Lorsque les cookies tiers sont bloqués, le tableau de bord intégré ne peut pas accéder à son cookie de niveau supérieur, ce qui empêche l&#39;affichage des données de revenus personnalisées de l&#39;utilisateur.
Lorsque les cookies tiers sont désactivés, le widget "earnings.example" intégré à "dogsitting.example" n'a pas accès au cookie défini dans le contexte de premier niveau sur "earnings.example".

Tableaux de bord propriétaires

Si les trois domaines appartiennent à la même partie, envisagez d'utiliser SAA avec RWS. Avec SAA, earnings.example peut accéder à son cookie de premier niveau avec l'autorisation de l'utilisateur. Si cette partie utilise le earnings.example sur quatre domaines ou moins, déclarer des relations entre eux à l'aide de 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'est compatible qu'avec six sites dans un ensemble (un site principal et cinq sites associés).

Distribution des tableaux de bord à l'échelle

Dans les cas suivants, SAA et RWS ne sont peut-être pas la solution optimale:

  • Vous distribuez une solution de tableau de bord pour des sites tiers.
  • Plus de cinq sites intègrent votre widget de tableau de bord.

Dans ce cas, earnings.example doit envisager d'implémenter FedCM pour jouer le rôle de fournisseur d'identité. Cela signifie que l'utilisateur devra se connecter à dogsitting.example avec un compte géré par earnings.example.

FedCM propose une interface utilisateur personnalisable qui peut aider à communiquer clairement à l'utilisateur les informations 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'intégration earnings.example se verra accorder un accès au stockage de ses propres cookies de niveau supérieur sans invite utilisateur supplémentaire sur l'appel de l'API SAA.

Paramètres du tableau de bord spécifiques au site

Si les données n'ont pas besoin d'être partagées entre plusieurs sites, envisagez de partitionner vos cookies avec CHIPS. Les chips peuvent être utiles pour stocker des préférences spécifiques au site, comme la mise en page du tableau de bord ou les filtres.

Gérer les modes de paiement

Un autre flux courant consiste à permettre à l'utilisateur d'afficher et de modifier ses modes de paiement dans un élément intégré sans quitter le site hôte.

Considérons le flux suivant:

  • payments.example fournit un outil de gestion des paiements pouvant être intégré aux sites Web. Ce service stocke les données de paiement et les informations de session des utilisateurs.
  • shop.example est un site Web qui intègre l'outil payments.example pour permettre aux utilisateurs d'afficher, de modifier ou de choisir les modes de paiement préférés associés à leur compte shop.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 peut 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é. L'avantage principal de l'utilisation 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, ce 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, la SAA peut contribuer à assurer un fonctionnement correct en demandant l'accès au stockage.

Il arrive que les informations définies dans l'intégration ne doivent pas être partagées sur d'autres sites d'intégration. payments.example n'a peut-être besoin de stocker que des préférences utilisateur différentes pour chaque site d'intégration particulier. 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.

Une autre API expérimentale pouvant être utilisée dans ce parcours utilisateur est les pop-ups partitionnés. Lorsque l'utilisateur se connecte à payments.example dans un pop-in ouvert par shop.example, l'espace de 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 nécessite 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 tendances qui s'écartent de la norme. Par exemple, si un utilisateur change soudainement son adresse de livraison et effectue plusieurs achats importants à l'aide d'un nouvel appareil, le score de fraude potentiel peut augmenter. Les cookies de détection des fraudes sont généralement des cookies tiers, définis sur les sites des marchands par des fournisseurs de services de paiement ou des widgets de services de prévention des fraudes.

Bien que les restrictions de 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, des vérifications supplémentaires peuvent être nécessaires, comme la validation de l'identité.

Pour permettre la détection des fraudes lorsque les cookies tiers sont bloqués, envisagez d'intégrer l'API PST (Private State Tokens) à votre solution de détection des fraudes. Avec le PST, un fournisseur de services de paiement peut s'enregistrer en tant qu'émetteur de jetons et accorder aux utilisateurs des jetons qui ne reposent pas sur des cookies tiers. Ces jetons peuvent ensuite être utilisés sur les sites marchands pour vérifier si l'utilisateur est fiable. Pour en savoir plus sur l'implémentation, consultez la documentation destinée aux développeurs PST.

La Privacy Sandbox teste d'autres API de lutte contre la fraude.

Bouton de paiement personnalisé

Les boutons de paiement (par exemple, Payer avec <mode de paiement préféré>) intégrés aux sites marchands reposent souvent sur des informations intersites définies par le fournisseur de paiement. Cela permet de personnaliser l'expérience et les utilisateurs peuvent effectuer un 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 du bouton de paiement personnalisé.

Bien que la SAA puisse permettre l'accès au stockage, l'invite requise peut ne pas offrir une expérience utilisateur idéale.

Nous explorons une solution potentielle qui cible spécifiquement ce cas d'utilisation : les frames clôturés avec un accès aux données non partitionnées local. L'API est actuellement en cours de développement, et vous pouvez façonner son avenir. Essayez-la vous-même et envoyez-nous vos commentaires.

Obtenir de l'aide

Signalez les problèmes rencontrés sur goo.gle/report-3pc-broken. Vous pouvez également envoyer un formulaire de commentaires ou signaler un problème dans le dépôt GitHub de l'assistance réservée aux développeurs de la Privacy Sandbox.