Confira o impacto das mudanças nos cookies de terceiros nos seus fluxos de pagamentos

O Chrome está propondo uma nova experiência de escolha do usuário em relação aos cookies de terceiros. Você precisa preparar seu site para usuários que escolherem navegar sem cookies de terceiros.

Esta página contém informações sobre o que pode ser afetado pelas próximas mudanças.

Jornadas comuns dos usuários

Muitos fluxos de pagamento e compras dependem de cookies de terceiros. A tabela a seguir lista algumas jornadas do usuário que podem ser afetadas se os cookies de terceiros forem desativados e sugere APIs alternativas que os desenvolvedores podem usar para evitar interrupções. Esta lista pode não ser completa e pode ser atualizada à medida que mais soluções do Sandbox de privacidade forem disponibilizadas. Recomendamos que você compartilhe seu feedback se encontrar outros cenários afetados.

A melhor maneira de testar se os fluxos de usuários são afetados por restrições de cookies de terceiros é examiná-los com a flag de teste de cookies de terceiros ativada.

Para garantir que seu site funcione conforme o esperado, teste o fluxo a seguir com cookies de terceiros restritos:

  • Finalização de compra em vários sites: teste os fluxos de pagamento que dependem de um provedor de pagamento de terceiros (como o Pagar com <example-provider>). Confira se:
    • O redirecionamento acontece.
    • O gateway de pagamento é carregado corretamente.
    • O processo de pagamento pode ser concluído sem erros.
    • O usuário é redirecionado de volta ao seu site, como esperado.
  • Painéis de pagamentos: teste se os widgets do painel de transações funcionam como esperado com cookies de terceiros restritos. Verifique se o usuário pode:
    • Acesse o painel.
    • Confira todos os pagamentos como esperado.
    • Navegue sem erros entre diferentes seções do painel (por exemplo, histórico de transações, detalhes de pagamento).
  • Gerenciar formas de pagamento: teste se os widgets de gerenciamento de formas de pagamento funcionam como esperado. Com os cookies de terceiros bloqueados, teste se:
    • A adição ou exclusão de uma forma de pagamento funciona como esperado.
    • O pagamento com formas de pagamento salvas não é afetado.
  • Detecção de fraudes: compare como sua solução de detecção de fraudes funciona com e sem cookies de terceiros.
    • O bloqueio de cookies de terceiros introduz etapas extras, causando mais atrito para o usuário?
    • O recurso ainda pode detectar padrões suspeitos quando os cookies de terceiros são bloqueados no navegador?
  • Botão de finalização da compra personalizado: teste se os botões de pagamento são renderizados corretamente com cookies de terceiros restritos.
    • O usuário ainda pode concluir compras mesmo que o botão personalizado não mostre o método preferido?

Finalização de compra entre sites

Alguns provedores de pagamento podem usar cookies de terceiros para permitir que os usuários acessem a conta em vários sites de comerciantes sem precisar fazer uma nova autenticação. Essa jornada do usuário pode ser afetada para quem escolhe navegar sem cookies de terceiros.

Formulários de finalização da compra incorporados

Considere os seguintes domínios:

  • O payment-provider.example oferece serviços de pagamento a sites de comerciantes e armazena dados de pagamento e sessão do usuário.
  • merchant.example é um site que incorpora um formulário de finalização de compra fornecido por payment-provider.example.

Um usuário acabou de fazer login em payment-provider.example (por exemplo, ao finalizar a compra em outro site). O usuário inicia um processo de finalização da compra em merchant.example.

Com cookies de terceiros disponíveis, o formulário de finalização de compra payment-provider.example incorporado em merchant.example teria acesso ao próprio cookie de sessão de nível superior definido em payment-provider.example no contexto de nível superior. No entanto, se os cookies de terceiros forem bloqueados, a incorporação não terá acesso aos próprios cookies de nível superior.

O diagrama mostra uma interação com o site de um comerciante (merchant.example) que usa um widget de pagamento de um provedor externo (payment-provider.example). Quando os cookies de terceiros são bloqueados, o widget não pode acessar o cookie de nível superior, o que pode prejudicar a experiência do usuário.
Quando os cookies de terceiros estão desativados, o widget "payment-provider.example" não tem acesso ao cookie de sessão do usuário definido no contexto de nível superior em "payment-provider.example".

Uma solução personalizável com FedCM

payment-provider.example deve considerar a implementação do FedCM para atuar como um provedor de identidade. Essa abordagem pode ser adequada quando:

  • payment-provider.example está incorporado em sites de terceiros não relacionados.
  • payment-provider.example está incorporado em mais de cinco sites relacionados.

O principal benefício do FedCM é que a interface pode oferecer aos usuários mais contexto para as escolhas. Com a permissão do usuário, o FedCM permite o compartilhamento de dados personalizados entre a parte confiável (merchant.example) e o provedor de identidade (payment-provider.example). A parte confiável pode oferecer suporte a um ou mais provedores de identidade, e a interface do FedCM só será mostrada condicionalmente.

Dependendo das necessidades, os desenvolvedores podem escolher entre o modo passivo para que o prompt do FedCM apareça automaticamente quando o usuário estiver conectado com o provedor de identidade ou o modo ativo, quando o processo de login precisa ser acionado após uma ação do usuário, como clicar em um botão de finalização de compra.

O FedCM também funciona como um indicador de confiança para a API Storage Access (SAA), que permite que a incorporação acesse os cookies não particionados de nível superior depois que o usuário concorda em fazer login com o provedor da incorporação, sem a necessidade de uma solicitações adicionais do usuário.

Solução focada no acesso ao armazenamento

Outra API a ser considerada é a API Storage Access (SAA). Com o SAA, o usuário vai receber uma solicitação para permitir que a incorporação de payment-provider.example acesse os próprios cookies de nível superior. Se o usuário aprovar o acesso, o formulário poderá ser renderizado como quando os cookies de terceiros estão disponíveis.

Assim como no FedCM, o usuário vai precisar aprovar a solicitação em cada novo site em que o payment-provider.example estiver incorporado. Assista à demonstração da SAA para entender como a API funciona. Se a solicitação padrão de SAA não atender às suas necessidades, implemente o FedCM para uma experiência mais personalizada.

Reduzir a dificuldade do usuário em um pequeno número de sites relacionados

Se o site do comerciante e o provedor de pagamento pertencerem à mesma empresa, use a API Related Website Sets (RWS) para declarar relacionamentos entre domínios. Isso pode ajudar a reduzir a fricção do usuário: por exemplo, se insurance.example e payment-portal-insurance.example estiverem no mesmo RWS, payment-portal-insurance.example vai receber acesso automaticamente aos próprios cookies de nível superior quando o acesso ao armazenamento for solicitado na incorporação de payment-portal-insurance.example.

Outras soluções experimentais

Outra API experimental que pode ser útil nesse cenário é Pop-ups particionados. A API está atualmente em fase ativa de desenvolvimento.

Com os pop-ups particionados, o usuário pode ser solicitado a inserir as credenciais para fazer login em payment-provider.example em um pop-up aberto por merchant.example. O armazenamento será particionado pelo merchant.example de abertura. Nesse caso, a incorporação payment-provider.example terá acesso aos valores de armazenamento definidos no pop-up. Com essa solução, o usuário vai precisar fazer login no provedor de pagamento em todos os sites.

Alguns provedores de pagamento oferecem um serviço que gera um link de pagamento, que renderiza uma página de finalização da compra personalizada para o site de um comerciante. Um serviço de link de pagamento e um portal do usuário para o provedor de pagamento geralmente são implementados em domínios diferentes, por exemplo, payment-provider.example e payment-link.example.

O payment-link.example incorpora um formulário de finalização de compra fornecido por payment-provider.example. Essa é uma variação do padrão de formulário de finalização de compra incorporado. FedCM, SAA e RWS também são boas opções para esse caso.

Painéis de pagamentos

Alguns aplicativos mostram painéis de transações para os usuários em vários sites, fornecendo uma visão centralizada das atividades financeiras. Isso exige que o painel acesse dados específicos do usuário em vários domínios.

Considere os seguintes domínios:

  • O earnings.example fornece um painel de pagamentos que pode ser incorporado a vários aplicativos da Web. Esse serviço armazena dados de ganhos do usuário e informações de sessão.
  • catsitting.example e dogsitting.example são sites separados que incorporam o painel earnings.example.

Um usuário faz login na conta earnings.example. Quando eles acessam catsitting.example ou dogsitting.example, podem conferir os ganhos. O painel earnings.example incorporado depende de cookies de nível superior e exibe as informações de ganhos personalizadas do usuário.

Assim como em outros exemplos, a incorporação earnings.example não terá acesso aos cookies de nível superior com cookies de terceiros desativados.

Diagrama que ilustra um cenário em que as informações de ganhos de um usuário, hospedadas em earnings.example,
      são exibidas em um painel incorporado em dogsitting.example.  Quando os cookies de terceiros são bloqueados,
      o painel incorporado não consegue acessar o cookie de nível superior, o que impede a exibição dos dados de ganhos personalizados do usuário.
Quando os cookies de terceiros estão desativados, o widget "earnings.example" incorporado em "dogsitting.example" não tem acesso ao cookie definido no contexto de nível superior em "earnings.example".

Painéis próprios

Nos casos em que os três domínios pertencem à mesma parte, use o SAA com o RWS. Com o SAA, o earnings.example pode acessar o cookie de nível superior com a permissão do usuário. Se essa parte usar o earnings.example em quatro domínios ou menos, declarar relacionamentos entre eles com RWS pode proporcionar uma experiência de usuário mais suave.

Se a mesma parte incorporar o widget em mais de cinco domínios, ela não poderá declarar relacionamentos entre todos os sites de incorporação e o domínio do widget, já que o RWS só aceita até seis sites em um conjunto: um principal e cinco associados.

Distribuição de painéis escalonados

Nos casos a seguir, SAA e RWS podem não ser a solução ideal:

  • Você distribui uma solução de painel para sites de terceiros.
  • Você tem mais de cinco sites que incorporam o widget do painel.

Nesse caso, o earnings.example deve considerar a implementação do FedCM para atuar como um provedor de identidade. Isso significa que o usuário vai precisar fazer login no dogsitting.example com uma conta gerenciada por earnings.example.

O FedCM oferece uma interface personalizável que pode ajudar a comunicar claramente ao usuário quais informações estão sendo compartilhadas. Com o FedCM, o dogsitting.example pode solicitar earnings.example para compartilhar permissões personalizadas, por exemplo, para acessar dados de transações.

O FedCM também serve como um indicador de confiança para a API Storage Access, e a incorporação de earnings.example vai receber acesso de armazenamento aos próprios cookies de nível superior sem uma solicitação de usuário adicional na chamada da API SAA.

Configurações do painel específicas do site

Se os dados não precisarem ser compartilhados em vários sites, considere particionar os cookies com o CHIPS. O CHIPS pode ser útil para armazenar preferências específicas do site, por exemplo, o layout do painel ou os filtros.

Gerenciar formas de pagamento

Outro fluxo comum é o usuário visualizar e editar as formas de pagamento em uma incorporação sem sair do site de hospedagem.

Considere o seguinte fluxo:

  • O payments.example oferece uma ferramenta de gerenciamento de pagamentos que pode ser incorporada a sites. Esse serviço armazena dados de pagamento do usuário e informações de sessão.
  • shop.example é um site que incorpora a ferramenta payments.example para permitir que os usuários visualizem, editem ou escolham as formas de pagamento preferidas associadas à conta shop.example.

Os provedores de pagamento que implementam o gerenciamento de métodos de pagamento também precisam considerar se tornar um provedor de identidade com o FedCM. Com o FedCM, o usuário poderá fazer login na parte confiável (shop.example) usando a conta gerenciada pelo provedor de identidade (payments.example).

Com a permissão do usuário, o FedCM permite o compartilhamento de dados personalizados entre a parte confiável e o provedor de identidade. O principal benefício do uso do FedCM é que a interface pode oferecer aos usuários mais contexto para as escolhas deles. Ele também atua como um sinal de confiança para a API Storage Access, que permite que a incorporação acesse os cookies de nível superior.

Com os cookies de terceiros desativados, a incorporação de payments.example não terá acesso aos cookies de nível superior. Nesse caso, a SAA pode ajudar a garantir a operação adequada solicitando acesso ao armazenamento.

Às vezes, as informações definidas na incorporação não precisam ser compartilhadas em outros sites de incorporação. O payments.example pode precisar armazenar apenas diferentes preferências do usuário para cada site de incorporação específico. Nesse caso, considere particionar cookies usando CHIPS. Com CHIPS, o cookie definido em payments.example incorporado em shop.example não será acessível por payments.example incorporado em another-shop.example.

Outra API experimental que pode ser usada nesse fluxo de usuários é Pop-ups particionados. Quando o usuário faz login em payments.example em um pop-up aberto por shop.example, o armazenamento é particionado pelo abridor, e a incorporação de payments.example tem acesso aos valores de armazenamento definidos no pop-up. No entanto, essa abordagem exige que os usuários insiram credenciais para fazer login no provedor de pagamento em todos os sites.

Detecção de fraude

Os sistemas de análise de risco podem analisar os dados armazenados em cookies para identificar padrões que se desviam da norma. Por exemplo, se um usuário mudar de repente o endereço de entrega e fizer várias compras grandes usando um novo dispositivo, a pontuação de possível fraude poderá aumentar. Os cookies de detecção de fraude geralmente são cookies de terceiros definidos nos sites dos comerciantes pelos provedores de pagamentos ou widgets de serviços de prevenção de fraudes.

Embora as restrições de cookies de terceiros não quebrem os sistemas de detecção de fraude, elas podem criar mais atrito para o usuário. Se o sistema não conseguir verificar com segurança se um usuário é legítimo devido a cookies bloqueados, ele poderá exigir verificações adicionais, como a verificação de identidade.

Para oferecer suporte à detecção de fraudes quando os cookies de terceiros são bloqueados, considere integrar a API Private State Tokens (PST) à sua solução de detecção de fraudes. Com a PST, um provedor de pagamentos pode se registrar como um emissor de tokens e conceder aos usuários tokens que não dependem de cookies de terceiros. Esses tokens podem ser resgatados nos sites dos comerciantes para verificar se o usuário é confiável. Consulte a documentação para desenvolvedores de PST para conferir detalhes de implementação.

O Sandbox de privacidade está testando outras APIs antifraude.

Botão de finalização da compra personalizado

Os botões de pagamento (como Pagar com <forma de pagamento preferida>) incorporados aos sites dos comerciantes geralmente dependem de informações entre sites definidas pelo provedor de pagamento. Isso permite a personalização, e os usuários podem aproveitar uma finalização de compra tranquila com a forma de pagamento preferida. Se os cookies de terceiros forem bloqueados no navegador do usuário, isso poderá afetar a renderização do botão de pagamento personalizado.

Embora o SAA possa permitir o acesso ao armazenamento, a solicitação necessária pode não levar a uma experiência ideal do usuário.

Estamos analisando uma possível solução que visa especificamente este caso de uso: Frames delimitados com acesso local a dados não particionados. No momento, a API está em um estágio ativo de desenvolvimento, e você pode moldar o futuro dela. Teste por conta própria e envie seu feedback.

Ajuda

Informe qualquer falha em goo.gle/report-3pc-broken. Também é possível enviar um formulário de feedback ou registrar um problema no GitHub no repositório de suporte ao desenvolvedor do Sandbox de privacidade.