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

Сторонние файлы cookie могут быть заблокированы ограничениями браузера, настройками пользователя , флагами разработчика или политикой предприятия .

Вам необходимо убедиться, что ваш сайт или сервис обеспечивает всем пользователям отличный опыт использования, независимо от того, доступны ли сторонние файлы 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 встроенная в merchant.example форма оформления заказа payment-provider.example будет иметь доступ к собственному файлу cookie сеанса верхнего уровня, установленному на payment-provider.example в контексте верхнего уровня. Однако, если сторонние файлы cookie заблокированы, встроенная форма не будет иметь доступа к собственным файлам cookie верхнего уровня.

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

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

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

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

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

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

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

Оплата по ссылке

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

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

Панели управления платежами

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

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

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

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

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

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

Если все три домена принадлежат одной стороне, рассмотрите возможность использования 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 пользователь сможет войти в систему Relying Party ( 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 в popin, открытом с помощью shop.example , хранилище будет разделено открывающим инструментом, и встроенный payments.example получит доступ к значениям хранилища, заданным в popin. Однако этот подход требует от пользователя ввода учётных данных для входа в платёжную систему на каждом сайте.

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

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

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

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

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

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

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

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

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

Помощь и обратная связь

Если у вас есть вопросы или отзывы о путях пользователя или API, описанных в этом руководстве, вы можете поделиться своим отзывом .