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

Cookies de terceiros podem ser bloqueados por restrições do navegador, configurações do usuário, flags do desenvolvedor ou política empresarial.

É necessário garantir que seu site ou serviço ofereça uma ótima experiência para todos os usuários, com ou sem cookies de terceiros.

Esta página contém informações sobre jornadas comuns do usuário que podem ser afetadas quando os cookies de terceiros são bloqueados.

Jornadas comuns dos usuários

Muitos fluxos de trabalho 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 falhas. Essa lista não é completa e pode ser atualizada à medida que mais soluções do Sandbox de privacidade forem disponibilizadas.

Jornada do usuário	APIs recomendadas
Finalização da compra entre sites	FedCM Conjuntos de sites relacionados API Storage Access (SAA) sciencePop-ups particionados
Painéis de pagamentos	FedCM API Storage Access (SAA) Conjuntos de sites relacionados CHIPS
Gerenciar formas de pagamento	FedCM API Storage Access (SAA) Conjuntos de sites relacionados CHIPS sciencePop-ins particionados
Detecção de fraude	Tokens de estado particular
Botão de finalização de compra personalizado	scienceFrames isolados com acesso local a dados não particionados

Teste as jornadas do usuário relacionadas a pagamentos

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

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

• Finalização da compra em vários sites: teste os fluxos de pagamento que dependem de um provedor de pagamento terceirizado (como Pagar com <example-provider>). Verifique se:
  • O redirecionamento é feito com sucesso.
  • 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.
  • Ver todos os pagamentos conforme o esperado.
  • Navegar sem erros entre as 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:
  • Adicionar ou excluir uma forma de pagamento funciona como esperado.
  • O pagamento com formas de pagamento salvas anteriormente não será 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?
  • Ele 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ções 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 a autenticação novamente. Essa jornada do usuário pode ser afetada para quem escolhe navegar sem cookies de terceiros.

Formulários de pagamento 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 concluir a finalização da compra em outro site). O usuário inicia um processo de finalização da compra em merchant.example.

Com os 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 estiverem bloqueados, a incorporação não terá acesso aos próprios cookies de nível superior.

Uma solução personalizável com a FedCM

payment-provider.example deve considerar a implementação da 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 da FedCM é que a interface pode oferecer aos usuários mais contexto para as escolhas deles. 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 escolher 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 a solicitação da FedCM apareça automaticamente quando o usuário fizer login com o provedor de identidade ou o modo ativo, quando o processo de login for acionado após uma ação do usuário, como clicar em um botão de finalização de compra.

A 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ção adicional do usuário.

Solução focada no acesso ao armazenamento

Outra API a ser considerada é a API Storage Access (SAA). Com a SAA, o usuário vai receber uma solicitação para permitir que a incorporação 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 acontece com o FedCM, o usuário precisa aprovar a solicitação em todos os novos sites em que o payment-provider.example está incorporado. Confira a demonstração da SAA para entender como a API funciona. Se o pedido padrão do SAA não atender às suas necessidades, implemente a FedCM para uma experiência mais personalizada.

Reduzir o atrito do usuário em um pequeno número de sites relacionados

Se o site do comerciante e o provedor de pagamentos pertencerem à mesma empresa, use a API Conjuntos de sites relacionados (RWS, na sigla em inglês) para declarar relações entre domínios. Isso pode ajudar a reduzir o atrito do usuário. Por exemplo, se insurance.example e payment-portal-insurance.example estiverem no mesmo RWS, payment-portal-insurance.example vai receber automaticamente acesso aos próprios cookies de nível superior quando o acesso ao armazenamento for solicitado na incorporação payment-portal-insurance.example.

Outras soluções experimentais

Outra API experimental que pode ser útil nesse cenário é a Partitioned Popins (link em inglês). No momento, a API está em fase de desenvolvimento ativo.

Com os pop-ins particionados, o usuário pode ser solicitado a inserir as credenciais para fazer login no payment-provider.example em um pop-in aberto pelo 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-in. Com essa solução, o usuário precisa fazer login no provedor de pagamento em todos os sites.

Finalizações de compra com link de pagamento

Alguns provedores de pagamento oferecem um serviço que gera um link de pagamento, que renderiza uma página de finalização de 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 pagamentos geralmente são implementados em domínios diferentes, por exemplo, payment-provider.example e payment-link.example.

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 aos usuários em vários sites, oferecendo 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 oferece 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 da sessão.
• catsitting.example e dogsitting.example são sites separados que incorporam o painel earnings.example.

Um usuário faz login na conta do 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 mostra as informações de ganhos personalizados do usuário.

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

Painéis próprios

Nos casos em que todos os três domínios pertencem à mesma parte, use SAA com RWS. Com a 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 ou menos domínios, declarar relações entre eles com o RWS pode proporcionar uma experiência do usuário mais tranquila.

Se a mesma parte incorporar o widget em mais de cinco domínios, não será possível declarar relações 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, a SAA e o 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, earnings.example precisa considerar a implementação da FedCM para atuar como um provedor de identidade. Isso significa que o usuário precisa fazer login no dogsitting.example com uma conta gerenciada pelo 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 que o earnings.example compartilhe permissões personalizadas, por exemplo, para acessar dados de transação.

A FedCM também serve como um indicador de confiança para a API Storage Access, e a incorporação earnings.example vai receber acesso de armazenamento aos próprios cookies de nível superior sem uma solicitação adicional do usuário 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 seus cookies com CHIPS. Os CHIPS podem ser úteis para armazenar preferências específicas do site, como o layout do painel ou 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 host.

Considere o seguinte fluxo:

• 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 da sessão.
• shop.example é um site que incorpora a ferramenta payments.example para permitir que os usuários vejam, editem ou escolham as formas de pagamento preferidas associadas à conta shop.example.

Os provedores de pagamento que implementam o gerenciamento de formas de pagamento também precisam considerar se tornar um provedor de identidade com a FedCM. Com a FedCM, o usuário poderá fazer login na parte confiante (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 de usar a FedCM é que a interface pode oferecer aos usuários mais contexto para as escolhas deles. Ele também atua como um indicador 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 do payments.example não terá acesso aos cookies de nível superior. Nesse caso, o SAA pode ajudar a garantir o funcionamento adequado solicitando acesso ao armazenamento.

Às vezes, as informações definidas na incorporação não precisam ser compartilhadas em outros sites de incorporação. payments.example pode precisar armazenar apenas preferências diferentes de usuários em cada site de incorporação específico. Nesse caso, considere particionar cookies usando CHIPS. Com o 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 é a Partitioned Popins. Quando o usuário faz login em payments.example em um pop-in 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-in. No entanto, essa abordagem exige que os usuários insiram credenciais para fazer login no provedor de pagamentos 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 repentinamente o endereço de entrega e fizer várias compras grandes usando um novo dispositivo, a pontuação de fraude em potencial poderá aumentar. Os cookies de detecção de fraude geralmente são de terceiros, definidos nos sites dos comerciantes por provedores de pagamento ou widgets de serviços de prevenção de fraudes.

Embora as restrições de cookies de terceiros não devam prejudicar os sistemas de detecção de fraude, elas podem criar mais atrito para o usuário. Se o sistema não puder verificar com segurança se um usuário é legítimo devido a cookies bloqueados, ele poderá exigir verificações adicionais, como a conclusão da confirmaçã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 emissor de tokens e conceder aos usuários tokens que não dependem de cookies de terceiros. Esses tokens podem ser resgatados em sites de comerciantes para verificar se o usuário é confiável. Consulte a documentação para desenvolvedores da PST para detalhes da implementação.

O Sandbox de privacidade está testando outras APIs antifraude.

Botão de finalização de compra personalizado

Os botões de pagamento (como Pagar com <forma de pagamento preferida>) incorporados em sites de comerciantes geralmente dependem de informações entre sites definidas pelo provedor de pagamentos. 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 estiverem bloqueados no navegador do usuário, isso poderá afetar a renderização do botão de pagamento personalizado.

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

Estamos explorando uma possível solução que tem como foco esse caso de uso: Fenced Frames com acesso a dados locais não particionados. A API está em fase de desenvolvimento, e você pode moldar o futuro dela. Teste por conta própria e envie feedback.

Ajuda e feedback

Se você tiver dúvidas ou feedback sobre as jornadas do usuário ou as APIs descritas neste guia, compartilhe sua opinião.