Проверьте влияние изменений сторонних файлов cookie на рабочие процессы ваших платежей.

Chrome предлагает новый опыт выбора пользователями в отношении сторонних файлов cookie. Вам необходимо подготовить свой сайт для пользователей, которые предпочитают просматривать его без сторонних файлов cookie.

На этой странице содержится информация о том, на что могут повлиять предстоящие изменения.

Типичные пути пользователя

Многие процессы оплаты и покупок основаны на сторонних файлах cookie. В следующей таблице перечислены некоторые действия пользователя, на которые может повлиять отключение сторонних файлов cookie, и предлагаются альтернативные API, которые разработчики могут использовать, чтобы избежать сбоев. Этот список может не быть исчерпывающим и может обновляться по мере появления новых решений Privacy Sandbox. Мы рекомендуем вам поделиться своими отзывами, если вы столкнетесь с какими-либо дополнительными затронутыми сценариями.

Лучший способ проверить, влияют ли на ваши пользовательские потоки ограничения сторонних файлов cookie, — пройти через них с включенным флагом проверки сторонних файлов cookie .

Чтобы убедиться, что ваш веб-сайт работает должным образом, протестируйте следующий процесс с ограниченными сторонними файлами cookie:

  • Межсайтовая проверка . Проверьте потоки платежей, которые зависят от стороннего поставщика платежей (например, Pay with <example-provider>) . Убедитесь, что:
    • Перенаправление происходит успешно.
    • Платежный шлюз загружен правильно.
    • Процесс оплаты может быть завершен без ошибок.
    • Пользователь перенаправляется обратно на ваш сайт, как и ожидалось.
  • Панели мониторинга платежей : проверьте, что виджеты панели мониторинга транзакций работают должным образом с ограничением сторонних файлов cookie. Убедитесь, что пользователь может:
    • Получите доступ к панели управления.
    • См. все платежи, как ожидалось.
    • Безошибочно перемещайтесь между различными разделами панели управления (например, историей транзакций, сведениями о платежах).
  • Управление способами оплаты : проверьте, что виджеты управления способами оплаты работают должным образом. Если сторонние файлы cookie заблокированы, проверьте следующее:
    • Добавление или удаление способа оплаты работает должным образом.
    • На оплату ранее сохраненными способами оплаты это не повлияет.
  • Обнаружение мошенничества . Сравните, как работает ваше решение для обнаружения мошенничества со сторонними файлами cookie и без них.
    • Приводит ли блокировка сторонних файлов cookie к дополнительным шагам, вызывающим дополнительные трудности для пользователей?
    • Может ли он по-прежнему обнаруживать подозрительные закономерности, когда сторонние файлы cookie блокируются в браузере?
  • Персонализированная кнопка оформления заказа . Проверьте правильность отображения кнопок оплаты с ограничением сторонних файлов cookie.
    • Может ли пользователь по-прежнему совершать покупки, даже если на персонализированной кнопке не отображается предпочтительный способ?

Межсайтовые проверки

Некоторые поставщики платежных услуг могут полагаться на сторонние файлы cookie, чтобы позволить пользователям получать доступ к своей учетной записи на нескольких сайтах торговых точек без необходимости повторной аутентификации. На этот путь пользователя могут повлиять те, кто предпочитает просматривать сайты без сторонних файлов cookie.

Встроенные формы оформления заказа

Рассмотрим следующие домены:

  • payment-provider.example предоставляет платежные услуги сайтам продавцов и хранит данные пользовательских платежей и сеансов.
  • merchant.example — это веб-сайт, на котором встроена форма оформления заказа, предоставленная payment-provider.example .

Пользователь только что вошел в систему payment-provider.example (например, при оформлении заказа на другом сайте). Пользователь инициирует процесс оформления заказа на merchant.example .

При наличии сторонних файлов cookie форма оформления заказа payment-provider.example встроенная в merchant.example , будет иметь доступ к собственному сеансовому файлу cookie верхнего уровня, установленному в payment-provider.example в контексте верхнего уровня. Однако если сторонние файлы cookie заблокированы, у встраиваемого файла не будет доступа к собственным файлам cookie верхнего уровня.

На диаграмме показано взаимодействие с веб-сайтом продавца (merchant.example), использующим платежный виджет стороннего поставщика (pay-provider.example). Когда сторонние файлы cookie блокируются, виджет не может получить доступ к своим файлам cookie верхнего уровня, что может нарушить работу пользователя.
Если сторонние файлы cookie отключены, виджет «Payment-provider.example» не будет иметь доступа к файлам cookie сеанса пользователя, установленным в контексте верхнего уровня в «Payment-provider.example».

Настраиваемое решение с FedCM

payment-provider.example следует рассмотреть возможность внедрения FedCM в качестве поставщика удостоверений. Этот подход может быть полезен, если:

  • payment-provider.example встроен в несвязанные сторонние сайты.
  • payment-provider.example встроен более чем в пять связанных сайтов.

Основное преимущество FedCM заключается в том, что пользовательский интерфейс может предоставить пользователям больше контекста для их выбора. С разрешения пользователя FedCM позволяет обмениваться пользовательскими данными между проверяющей стороной ( merchant.example ) и поставщиком удостоверений ( payment-provider.example ). Проверяющая сторона может выбрать поддержку одного или нескольких поставщиков удостоверений, а пользовательский интерфейс FedCM будет отображаться только при определенных условиях .

В зависимости от потребностей разработчики могут выбирать между пассивным режимом, в котором приглашение FedCM появляется автоматически, когда пользователь входит в систему с помощью поставщика удостоверений, или активным режимом, когда процесс входа в систему должен запускаться после действия пользователя, например нажатия кнопки оформления заказа.

FedCM также действует как сигнал доверия для API доступа к хранилищу (SAA) , который позволяет внедрению получать доступ к своим неразделенным файлам cookie верхнего уровня после того, как пользователь соглашается войти в систему с поставщиком внедрения, без необходимости дополнительного запроса пользователя.

Решение, ориентированное на доступ к хранилищу

Еще один API, который следует рассмотреть, — это Storage Access API (SAA) . При использовании SAA пользователю будет предложено разрешить встраиванию payment-provider.example доступ к собственным файлам cookie верхнего уровня. Если пользователь разрешает доступ, форма может отображаться так же, как и при наличии сторонних файлов cookie.

Как и в случае с FedCM, пользователю придется одобрить запрос на каждом новом сайте, на котором встроен payment-provider.example . Посмотрите демонстрацию SAA , чтобы понять, как работает API. Если приглашение SAA по умолчанию не соответствует вашим потребностям, рассмотрите возможность внедрения FedCM для более индивидуального использования.

Уменьшите неудобства для пользователей на небольшом количестве связанных сайтов.

Если и сайт продавца, и поставщик платежей принадлежат одной и той же компании, вы можете использовать API наборов связанных веб-сайтов (RWS) для объявления связей между доменами. Это может помочь уменьшить неудобства для пользователей: например, если insurance.example и payment-portal-insurance.example находятся в одном RWS, payment-portal-insurance.example автоматически получит доступ к своим собственным файлам cookie верхнего уровня, когда доступ к хранилищу запрашивается во встраивании payment-portal-insurance.example .

Другие экспериментальные решения

Еще один экспериментальный API, который может оказаться полезным в этом сценарии, — Partitioned Popins . API в настоящее время находится на активной стадии разработки.

При использовании разделенных всплывающих окон пользователю может быть предложено ввести свои учетные данные для входа в payment-provider.example в всплывающем окне, открытом merchant.example . Хранилище будет разделено открывающим файлом merchant.example . В этом случае встраивание payment-provider.example будет иметь доступ к значениям хранилища, установленным во всплывающем окне. Благодаря этому решению пользователю придется входить в систему платежной системы на каждом сайте.

Некоторые поставщики платежных услуг предлагают услугу, которая генерирует ссылку для оплаты, которая отображает специальную страницу оформления заказа для сайта продавца. Служба платежных ссылок и пользовательский портал для поставщика платежей часто реализуются на разных доменах, например, payment-provider.example и payment-link.example .

payment-link.example встраивает форму оформления заказа, предоставленную payment-provider.example . Это вариант шаблона встроенной формы оформления заказа . FedCM , SAA и RWS также являются хорошими вариантами для рассмотрения в этом случае.

Платежные панели

Некоторые приложения отображают панели мониторинга транзакций своим пользователям на нескольких сайтах, обеспечивая централизованное представление их финансовой деятельности. Для этого необходима панель мониторинга для доступа к пользовательским данным в нескольких доменах.

Рассмотрим следующие домены:

  • earnings.example предоставляет панель выплат, которую можно встроить в различные веб-приложения. Этот сервис хранит данные о доходах пользователей и информацию о сеансах.
  • catsitting.example и dogsitting.example – это отдельные веб-сайты, на обоих из которых встроена earnings.example панельprofit.example.

Пользователь входит в свою учетную earnings.example . Когда они посещают catsitting.example или dogsitting.example , они могут просмотреть свои доходы. Встроенная earnings.example панельprofit.example использует файлы cookie верхнего уровня и отображает персонализированную информацию о доходах пользователя.

Как и в других примерах, встраивание earnings.example не будет иметь доступа к файлам cookie верхнего уровня, если сторонние файлы cookie отключены.

Диаграмма, иллюстрирующая сценарий, в котором информация о доходах пользователя, размещенная на сайтеprofit.example,       отображается на встроенной панели мониторинга на сайте Dogsitting.example.  Когда сторонние файлы cookie блокируются,       встроенная информационная панель не может получить доступ к файлам cookie верхнего уровня, что предотвращает отображение персонализированных данных о доходах пользователя.
Когда сторонние файлы cookie отключены, виджет «earnings.example», встроенный в «dogsitting.example», не будет иметь доступа к файлам cookie, установленным в контексте верхнего уровня в «earnings.example».

Собственные информационные панели

В случаях, когда все три домена принадлежат одной стороне, рассмотрите возможность использования SAA вместе с RWS . С помощью SAA earnings.example может получить доступ к своему файлу cookie верхнего уровня с разрешения пользователя. Если эта сторона использует earnings.example на четырех или меньшем количестве доменов, объявление связей между ними с помощью RWS может обеспечить более удобный пользовательский интерфейс.

Если одна и та же сторона встраивает виджет в более чем пять доменов, она не может объявить связи между всеми сайтами внедрения и доменом виджета, поскольку RWS поддерживает только до шести сайтов в наборе — один основной и пять связанных сайтов.

Распространение масштабируемых информационных панелей

В следующих случаях SAA и RWS могут оказаться не оптимальным решением:

  • Вы распространяете решение информационной панели для сторонних сайтов.
  • У вас есть более пяти сайтов, на которых встроен виджет вашей информационной панели.

В этом случае earnings.example следует рассмотреть возможность внедрения FedCM в качестве поставщика удостоверений. Это означает, что пользователю необходимо будет войти в dogsitting.example с учетной записью, управляемой earnings.example .

FedCM предлагает настраиваемый пользовательский интерфейс, который может помочь четко сообщить пользователю, какая информация передается. С помощью FedCM dogsitting.example может earnings.example для предоставления специальных разрешений , например, для доступа к данным транзакций.

FedCM также служит сигналом доверия для API доступа к хранилищу , а earnings.example будет предоставлен доступ к хранилищу для его собственных файлов cookie верхнего уровня без дополнительного запроса пользователя при вызове API SAA.

Настройки информационной панели для конкретного сайта

Если данные не нужно передавать на несколько сайтов, рассмотрите возможность разделения файлов cookie с помощью CHIPS . CHIPS может быть полезен для хранения настроек, специфичных для сайта, например макета информационной панели или фильтров.

Управление способами оплаты

Другой распространенный процесс — пользователь может просматривать и редактировать свои способы оплаты во вставке, не покидая хост-сайт.

Рассмотрим следующий поток:

  • payments.example предоставляет инструмент управления платежами, который можно встроить на веб-сайты. Этот сервис хранит данные о платежах пользователя и информацию о сеансе.
  • shop.example — это веб-сайт, на котором встроен инструмент payments.example , позволяющий пользователям просматривать, редактировать или выбирать предпочтительные способы оплаты, связанные с их учетной записью shop.example .

Поставщикам платежей, реализующим управление способами оплаты, также следует рассмотреть возможность стать поставщиком удостоверений с помощью FedCM . С помощью FedCM пользователь сможет войти в проверяющую сторону ( shop.example ), используя учетную запись, управляемую поставщиком удостоверений ( payments.example ).

С разрешения пользователя FedCM позволяет обмениваться пользовательскими данными между проверяющей стороной и поставщиком удостоверений. Основное преимущество использования FedCM заключается в том, что пользовательский интерфейс может предоставить пользователям больше контекста для их выбора. Он также действует как сигнал доверия для API доступа к хранилищу , который позволяет встраиванию получать доступ к файлам cookie верхнего уровня.

Если сторонние файлы cookie отключены, вставка payments.example не будет иметь доступа к файлам cookie верхнего уровня. В этом случае SAA может помочь обеспечить правильную работу, запросив доступ к хранилищу.

Иногда информацию, установленную во встраивании, не требуется распространять на другие сайты встраивания. payments.example может потребоваться хранить только разные пользовательские настройки для каждого конкретного сайта внедрения. В этом случае рассмотрите возможность разделения файлов cookie с помощью CHIPS . При использовании CHIPS файл cookie, установленный в файле payments.example , встроенном в shop.example не будет доступен для файла payments.example встроенного в another-shop.example .

Еще один экспериментальный API, который потенциально можно использовать в этом пользовательском потоке, — Partitioned Popins . Когда пользователь входит в систему payments.example в всплывающем окне, открытом shop.example , хранилище будет разделено открывающим элементом, и встраиваемый файл payments.example получит доступ к значениям хранилища, установленным во всплывающем окне. Однако этот подход требует от пользователей ввода учетных данных для входа в систему платежной системы на каждом сайте.

Обнаружение мошенничества

Системы анализа рисков могут анализировать данные, хранящиеся в файлах cookie, чтобы выявлять закономерности, отклоняющиеся от нормы. Например, если пользователь внезапно меняет адрес доставки и совершает несколько крупных покупок с использованием нового устройства, вероятность мошенничества может возрасти. Файлы cookie для обнаружения мошенничества обычно представляют собой сторонние файлы cookie, устанавливаемые на сайтах торговцев платежными системами или виджетами служб предотвращения мошенничества.

Хотя ограничения сторонних файлов cookie не должны нарушать работу систем обнаружения мошенничества, они могут создавать дополнительные трудности для пользователей. Если система не может с уверенностью проверить легитимность пользователя из-за заблокированных файлов cookie, ей могут потребоваться дополнительные проверки, например проверка личности.

Чтобы обеспечить обнаружение мошенничества при блокировке сторонних файлов cookie, рассмотрите возможность интеграции API токенов частного состояния (PST) в ваше решение для обнаружения мошенничества. С помощью PST поставщик платежей может зарегистрироваться в качестве эмитента токенов и предоставлять пользователям токены, которые не зависят от сторонних файлов cookie. Эти токены можно затем обменять на торговых сайтах, чтобы проверить, заслуживает ли пользователь доверия. Подробности реализации см. в документации разработчика PST .

Privacy Sandbox экспериментирует с другими API для борьбы с мошенничеством.

Персонализированная кнопка оформления заказа

Кнопки оплаты (например, «Оплатить с помощью <предпочитаемый способ оплаты>» ), встроенные в сайты продавцов, часто полагаются на межсайтовую информацию, установленную поставщиком платежей. Это обеспечивает персонализацию, и пользователи могут легко оформить заказ, выбрав предпочитаемый им способ оплаты. Если сторонние файлы cookie заблокированы в браузере пользователя, это может повлиять на отображение персонализированной кнопки оплаты.

Хотя SAA может обеспечить доступ к хранилищу, требуемый запрос может не обеспечить идеального взаимодействия с пользователем.

Мы изучаем потенциальное решение, специально предназначенное для этого варианта использования: изолированные фреймы с локальным доступом к неразделенным данным . API в настоящее время находится на активной стадии разработки, и вы можете формировать его будущее. Попробуйте сами и оставьте отзыв .

Получить помощь

О любых поломках сообщайте по адресу goo.gle/report-3pc-broken . Вы также можете отправить форму обратной связи или сообщить о проблеме на GitHub в репозитории поддержки разработчиков Privacy Sandbox .