Chrome propone una nueva experiencia de elección del usuario con respecto a las cookies de terceros. Debes preparar tu sitio para los usuarios que elijan navegar sin cookies de terceros.
En esta página, encontrarás información sobre lo que podría verse afectado por los próximos cambios.
Recorrido comunes de los usuarios
Muchos flujos de trabajo de pago y compra dependen de cookies de terceros. En la siguiente tabla, se enumeran algunos recorridos del usuario que pueden verse afectados si se inhabilitan las cookies de terceros y se sugieren APIs alternativas que los desarrolladores pueden usar para evitar interrupciones. Es posible que esta lista no sea exhaustiva y pueda actualizarse a medida que estén disponibles más soluciones de Privacy Sandbox. Te recomendamos que compartas tus comentarios si encuentras otras situaciones afectadas.
Prueba tus recorridos del usuario relacionados con los pagos
La mejor manera de probar si tus flujos de usuarios se ven afectados por las restricciones de las cookies de terceros es revisarlos con la marca de prueba de cookies de terceros habilitada.
Para asegurarte de que tu sitio web funcione según lo previsto, prueba el siguiente flujo con las cookies de terceros restringidas:
- Confirmación de la compra en varios sitios: Prueba los flujos de pago que dependen de un proveedor de pagos externo (como Pay with <example-provider>). Asegúrate de lo siguiente:
- El redireccionamiento se realiza correctamente.
- La pasarela de pagos se carga correctamente.
- El proceso de pago se puede completar sin errores.
- Se redirecciona al usuario a tu sitio web como se espera.
- Paneles de pagos: Prueba que los widgets del panel de transacciones funcionen como se espera con las cookies de terceros restringidas. Verifica que el usuario pueda hacer lo siguiente:
- Accede al panel.
- Consulta todos los pagos como se espera.
- Navega sin errores entre las diferentes secciones del panel (p.ej., historial de transacciones, detalles del pago).
- Administrar las formas de pago: Prueba que los widgets de administración de formas de pago funcionen según lo esperado. Con las cookies de terceros bloqueadas, prueba lo siguiente:
- Agregar o quitar una forma de pago funciona como se espera.
- El pago con las formas de pago guardadas anteriormente no se verá afectado.
- Detección de fraudes: Compara el funcionamiento de tu solución de detección de fraudes con y sin cookies de terceros.
- ¿El bloqueo de cookies de terceros agrega pasos adicionales que generan fricciones adicionales para los usuarios?
- ¿Puede detectar patrones sospechosos cuando se bloquean las cookies de terceros en el navegador?
- Botón de confirmación de la compra personalizado: Prueba si los botones de pago se renderizan correctamente con las cookies de terceros restringidas.
- ¿El usuario puede completar las compras aunque el botón personalizado no muestre su método preferido?
Confirmaciones de la compra entre sitios
Algunos proveedores de pagos pueden usar cookies de terceros para permitir que los usuarios accedan a su cuenta en varios sitios de comercios sin necesidad de volver a autenticarse. Este recorrido del usuario podría verse afectado para quienes elijan navegar sin cookies de terceros.
Formularios de confirmación de la compra incorporados
Ten en cuenta los siguientes dominios:
payment-provider.example
proporciona servicios de pago a los sitios de comercios y almacena los datos de pago y sesión de los usuarios.merchant.example
es un sitio web que incorpora un formulario de confirmación de la compra proporcionado porpayment-provider.example
.
Un usuario acaba de acceder a payment-provider.example
(por ejemplo, mientras completa la confirmación de la compra en otro sitio). El usuario inicia un proceso de confirmación de la compra en merchant.example
.
Con las cookies de terceros disponibles, el formulario de confirmación de la compra payment-provider.example
incorporado en merchant.example
tendría acceso a su propia cookie de sesión de nivel superior establecida en payment-provider.example
en el contexto de nivel superior.
Sin embargo, si se bloquean las cookies de terceros, la incorporación no tendrá acceso a sus propias cookies de nivel superior.

Una solución personalizable con FedCM
payment-provider.example
debería considerar implementar FedCM para actuar como proveedor de identidad. Este enfoque puede ser adecuado en los siguientes casos:
payment-provider.example
está incorporado en sitios de terceros no relacionados.payment-provider.example
está incorporado en más de cinco sitios relacionados.
El principal beneficio de FedCM es que la IU puede proporcionarles a los usuarios más contexto para sus elecciones. Con el permiso del usuario, FedCM permite compartir datos personalizados entre la parte de confianza (merchant.example
) y el proveedor de identidad (payment-provider.example
). La parte de confianza puede admitir uno o más proveedores de identidad, y la IU de FedCM solo se mostrará de forma condicional.
Según las necesidades, los desarrolladores pueden elegir entre el modo pasivo para que el mensaje de FedCM aparezca automáticamente cuando el usuario accede con el proveedor de identidad o el modo activo, cuando el proceso de acceso debe activarse después de que el usuario realice una acción, como hacer clic en un botón de confirmación de la compra.
FedCM también actúa como un indicador de confianza para la API de Storage Access (SAA), lo que permite que la incorporación acceda a sus cookies sin particionar de nivel superior después de que el usuario acepta acceder con el proveedor de la incorporación, sin necesidad de una solicitud adicional del usuario.
Solución centrada en el acceso al almacenamiento
Otra API que debes tener en cuenta es la API de Storage Access (SAA).
Con SAA, se le pedirá al usuario que permita la incorporación de payment-provider.example
para acceder a sus propias cookies de nivel superior. Si el usuario aprueba el acceso, el formulario se puede renderizar como lo hace cuando hay cookies de terceros disponibles.
Al igual que con FedCM, el usuario deberá aprobar la solicitud en cada sitio nuevo en el que se incorpore payment-provider.example
. Consulta la demo de SAA para comprender cómo funciona la API.
Si la instrucción de la SAA predeterminada no se ajusta a tus necesidades, considera implementar FedCM para obtener una experiencia más personalizada.
Reduce los obstáculos para los usuarios en una pequeña cantidad de sitios relacionados
Si el sitio del comercio y el proveedor de pagos pertenecen a la misma empresa, puedes usar la API de conjuntos de sitios web relacionados (RWS) para declarar relaciones entre dominios. Esto puede ayudar a reducir la fricción del usuario: por ejemplo, si insurance.example
y payment-portal-insurance.example
están en el mismo RWS, payment-portal-insurance.example
obtendrá acceso automáticamente a sus propias cookies de nivel superior cuando se solicite acceso al almacenamiento dentro de la incorporación de payment-portal-insurance.example
.
Otras soluciones experimentales
Otra API experimental que podría ser útil en esta situación es Ventanas emergentes particionadas. Actualmente, la API se encuentra en una etapa de desarrollo activo.
Con los pop-ins particionados, se le puede solicitar al usuario que ingrese sus credenciales para acceder a payment-provider.example
dentro de un pop-in que abrió merchant.example
. El almacenamiento se particionará con el abridor merchant.example
. En este caso, la incorporación de payment-provider.example
tendrá acceso a los valores de almacenamiento establecidos en el pop-in. Con esta solución, el usuario deberá acceder al proveedor de pagos en todos los sitios.
Confirmaciones de la compra con el vínculo de pago
Algunos proveedores de pagos ofrecen un servicio que genera un vínculo de pago, que muestra una página de confirmación de la compra personalizada para el sitio de un comercio. A menudo, un servicio de vinculación de pagos y un portal de usuario para el proveedor de pagos se implementan en diferentes dominios, por ejemplo, payment-provider.example
y payment-link.example
.
payment-link.example
incorpora un formulario de confirmación de la compra proporcionado por payment-provider.example
. Esta es una variación del patrón de formulario de confirmación de la compra incorporado.
FedCM, SAA y RWS también son buenas opciones para considerar en este caso.
Paneles de pagos
Algunas aplicaciones muestran paneles de transacciones a sus usuarios en varios sitios, lo que proporciona una vista centralizada de sus actividades financieras. Esto requiere que el panel acceda a datos específicos del usuario en varios dominios.
Ten en cuenta los siguientes dominios:
earnings.example
proporciona un panel de pagos que se puede incorporar en varias aplicaciones web. Este servicio almacena los datos de ingresos del usuario y la información de la sesión.catsitting.example
ydogsitting.example
son sitios web separados que incorporan el panelearnings.example
.
Un usuario accede a su cuenta de earnings.example
. Cuando visiten catsitting.example
o dogsitting.example
, podrán ver sus ingresos. El panel earnings.example
incorporado se basa en cookies de nivel superior y muestra la información personalizada de los ingresos del usuario.
Al igual que en otros ejemplos, la incorporación de earnings.example
no tendrá acceso a sus cookies de nivel superior si las cookies de terceros están inhabilitadas.

Paneles propios
En los casos en que los tres dominios pertenezcan a la misma parte, considera usar la SAA junto con la RWS.
Con la SAA, earnings.example
puede obtener acceso a su cookie de nivel superior con el permiso del usuario. Si esta parte usa earnings.example
en cuatro dominios o menos, declarar relaciones entre ellos con RWS puede proporcionar una experiencia del usuario más fluida.
Si la misma parte incorpora el widget en más de cinco dominios, no puede declarar relaciones entre todos los sitios de incorporación y el dominio del widget, ya que RWS solo admite hasta seis sitios en un conjunto: uno principal y cinco asociados.
Distribución de paneles ajustados
En los siguientes casos, es posible que SAA y RWS no sean la solución óptima:
- Distribuyes una solución de panel para sitios de terceros.
- Tienes más de cinco sitios que incorporan tu widget de panel.
En este caso, earnings.example
debería considerar implementar FedCM para actuar como proveedor de identidad. Esto significa que el usuario deberá acceder a dogsitting.example
con una cuenta administrada por earnings.example
.
FedCM ofrece una IU personalizable que puede ayudar a comunicarle al usuario con claridad qué información se comparte. Con FedCM, dogsitting.example
puede solicitar a earnings.example
que comparta permisos personalizados, por ejemplo, para acceder a los datos de transacciones.
FedCM también funciona como un indicador de confianza para la API de Storage Access, y se le otorgará acceso de almacenamiento a sus propias cookies de nivel superior a la incorporación de earnings.example
sin un mensaje adicional para el usuario en la llamada a la API de SAA.
Configuración del panel específica del sitio
Si no es necesario que los datos se compartan en varios sitios, considera particionar tus cookies con CHIPS. Los CHIPS pueden ser útiles para almacenar preferencias específicas del sitio, por ejemplo, el diseño o los filtros del panel.
Administrar las formas de pago
Otro flujo común es que el usuario vea y edite sus formas de pago dentro de una incorporación sin salir del sitio host.
Considera el siguiente flujo:
payments.example
proporciona una herramienta de administración de pagos que se puede incorporar en sitios web. Este servicio almacena los datos de pago y la información de la sesión del usuario.shop.example
es un sitio web que incorpora la herramientapayments.example
para permitir que los usuarios vean, editen o elijan las formas de pago preferidas asociadas con su cuenta deshop.example
.
Los proveedores de pagos que implementen la administración de formas de pago también deberían considerar convertirse en proveedores de identidad con FedCM. Con el FedCM, el usuario podrá acceder a la Parte de confianza (shop.example
) con la cuenta que administra el proveedor de identidad (payments.example
).
Con el permiso del usuario, FedCM permite compartir datos personalizados entre la entidad de confianza y el proveedor de identidad. El principal beneficio de usar FedCM es que la IU puede proporcionarles a los usuarios más contexto para sus elecciones. También actúa como un indicador de confianza para la API de Storage Access, lo que permite que la incorporación acceda a sus cookies de nivel superior.
Si las cookies de terceros están inhabilitadas, la incorporación de payments.example
no tendrá acceso a sus cookies de nivel superior. En este caso, la SAA puede ayudar a garantizar el funcionamiento adecuado solicitando acceso al almacenamiento.
A veces, la información establecida dentro de la incorporación no se necesita compartir en otros sitios de incorporación. Es posible que payments.example
solo necesite almacenar diferentes preferencias del usuario
por cada sitio de incorporación en particular. En este caso, considera particionar las cookies con CHIPS. Con CHIPS, la cookie establecida en payments.example
incorporada en shop.example
no será accesible para payments.example
incorporada en another-shop.example
.
Otra API experimental que se puede usar en este flujo de usuarios es Ventanas emergentes particionadas.
Cuando el usuario accede a payments.example
dentro de un pop-up que abre shop.example
, el abridor particiona el almacenamiento y la incorporación de payments.example
tendrá acceso a los valores de almacenamiento establecidos dentro del pop-up. Sin embargo, este enfoque requiere que los usuarios ingresen credenciales para acceder al proveedor de pagos en todos los sitios.
Detección de fraudes
Los sistemas de análisis de riesgos pueden analizar los datos almacenados en las cookies para identificar patrones que se desvíen de la norma. Por ejemplo, si un usuario cambia de repente su dirección de envío y realiza varias compras grandes con un dispositivo nuevo, es posible que aumente la puntuación de fraude potencial. Por lo general, las cookies de detección de fraudes son cookies de terceros que los proveedores de pagos o los widgets de servicios de prevención de fraudes configuran en los sitios de los comercios.
Si bien las restricciones de cookies de terceros no deben interrumpir los sistemas de detección de fraudes, pueden generar fricciones adicionales para los usuarios. Si el sistema no puede verificar con seguridad que un usuario es legítimo debido a cookies bloqueadas, es posible que requiera verificaciones adicionales, como completar la verificación de identidad.
Para admitir la detección de fraudes cuando se bloquean las cookies de terceros, considera integrar la API de Private State Tokens (PST) en tu solución de detección de fraudes. Con PST, un proveedor de pagos puede registrarse como emisor de tokens y otorgarles a los usuarios tokens que no dependen de cookies de terceros. Luego, estos tokens se pueden canjear en los sitios de comercios para verificar si el usuario es confiable. Consulta la documentación para desarrolladores de PST para conocer los detalles de la implementación.
Privacy Sandbox está experimentando con otras APIs contra el fraude.
Botón de confirmación de compra personalizado
Los botones de pago (como Pay with <preferred payment method>) incorporados en los sitios de comercios suelen depender de la información entre sitios que establece el proveedor de pagos. Esto permite la personalización, y los usuarios pueden disfrutar de una confirmación de la compra sin problemas con su forma de pago preferida. Si se bloquean las cookies de terceros en el navegador del usuario, esto puede afectar la renderización del botón de pago personalizado.
Si bien la SAA podría permitir el acceso al almacenamiento, es posible que la solicitud requerida no genere una experiencia del usuario ideal.
Estamos explorando una posible solución que se enfoque específicamente en este caso de uso: marcos con acceso a datos no particionados locales. Actualmente, la API se encuentra en una etapa de desarrollo activo, y puedes darle forma a su futuro. Pruébala y envíanos comentarios.
Obtener ayuda
Denuncia cualquier falla que experimentes en goo.gle/report-3pc-broken. También puedes enviar un formulario de comentarios o informar un problema en GitHub en el repositorio de asistencia para desarrolladores de Privacy Sandbox.