Sprawdź wpływ zmian dotyczących plików cookie innych firm na Twoje procesy płatności

Chrome proponuje nowe rozwiązanie, które daje użytkownikom możliwość wyboru w sprawie plików cookie innych firm. Musisz przygotować swoją witrynę na potrzeby użytkowników, którzy zdecydują się na przeglądanie bez plików cookie innych firm.

Ta strona zawiera informacje o tym, na czym mogą polegać nadchodzące zmiany.

Typowe ścieżki użytkownika

Wiele procesów płatności i zakupów korzysta z plików cookie innych firm. W tabeli poniżej znajdziesz listę ścieżek użytkownika, które mogą zostać zakłócone, jeśli pliki cookie innych firm zostaną wyłączone, oraz sugestie dotyczące interfejsów API, których deweloperzy mogą użyć, aby uniknąć problemów. Ta lista może nie być wyczerpująca i może być aktualizowana w miarę udostępniania kolejnych rozwiązań Privacy Sandbox. Zachęcamy do przesłania opinii, jeśli natrafisz na inne scenariusze, na które ma wpływ ta zmiana.

Najlepszym sposobem na sprawdzenie, czy ograniczenia dotyczące plików cookie innych firm wpływają na ścieżki użytkownika, jest przetestowanie ich przy włączonej opcji testowania plików cookie innych firm.

Aby się upewnić, że Twoja witryna działa zgodnie z oczekiwaniami, przetestuj tę procedurę z ograniczonym dostępem do plików cookie innych firm:

  • Proces płatności w wielu witrynach: przetestuj procesy płatności, które korzystają z zewnętrznego dostawcy płatności (np. Płać za pomocą <nazwa-dostawcy>). Upewnij się, że:
    • Przekierowanie zostało wykonane.
    • Bramka płatności jest wczytana prawidłowo.
    • Proces płatności może być zakończony bez błędów.
    • Użytkownik zostaje przekierowany z powrotem do Twojej witryny zgodnie z oczekiwaniami.
  • Panele płatności: sprawdź, czy widżety panelu transakcji działają zgodnie z oczekiwaniami, gdy pliki cookie innych firm są ograniczone. Sprawdź, czy użytkownik może:
    • Otwórz panel.
    • Wszystkie płatności są zgodne z oczekiwaniami.
    • bezbłędnie poruszać się między różnymi sekcjami pulpitu (np. historia transakcji, szczegóły płatności);
  • Zarządzanie formami płatności: sprawdź, czy widżety zarządzania formami płatności działają zgodnie z oczekiwaniami. Po zablokowaniu plików cookie innych firm sprawdź, czy:
    • Dodawanie i usuwanie formy płatności działa zgodnie z oczekiwaniami.
    • Nie ma to wpływu na płacenie za pomocą wcześniej zapisanych form płatności.
  • Wykrywanie oszustw: porównaj działanie rozwiązania do wykrywania oszustw z wykorzystaniem plików cookie innych firm i bez nich.
    • Czy blokowanie plików cookie innych firm powoduje konieczność wykonania dodatkowych czynności, które mogą utrudnić użytkownikom korzystanie z usługi?
    • Czy nadal wykryje podejrzane wzorce, gdy pliki cookie innych firm są zablokowane w przeglądarce?
  • Przycisk płatności spersonalizowany: sprawdź, czy przyciski płatności są wyświetlane prawidłowo, gdy pliki cookie innych firm są ograniczone.
    • Czy użytkownik może nadal dokonywać zakupów, nawet jeśli spersonalizowany przycisk nie wyświetla jego preferowanej metody?

Płatność w wielu witrynach

Niektórzy dostawcy usług płatniczych mogą używać plików cookie innych firm, aby umożliwić użytkownikom dostęp do ich kont w wielu witrynach sprzedawców bez konieczności ponownego uwierzytelniania. Ta ścieżka użytkownika może być zaburzona w przypadku osób, które zdecydują się przeglądać internet bez plików cookie innych firm.

Wbudowane formularze płatności

Rozważ te domeny:

  • payment-provider.example zapewnia usługi płatności w witrynach sprzedawców oraz przechowuje dane o płatnościach i sesjach użytkowników.
  • merchant.example to witryna, która zawiera formularz płatności udostępniony przez payment-provider.example.

Użytkownik właśnie zalogował się na stronie payment-provider.example (np. podczas procesu płatności w innej witrynie). Użytkownik rozpoczyna proces płatności na stronie merchant.example.

W przypadku dostępnych plików cookie innych firm formularz payment-provider.example w ramach procesu płatności umieszczony na stronie merchant.example miałby dostęp do własnego najwyższego poziomu plików cookie sesji ustawionych na stronie payment-provider.example w kontekście najwyższego poziomu. Jeśli jednak pliki cookie innych firm są zablokowane, element osadzony nie będzie miał dostępu do własnych plików cookie najwyższego poziomu.

Diagram pokazuje interakcję z witryną sprzedawcy (merchant.example), która korzysta z widżetu płatności od zewnętrznego dostawcy (payment-provider.example). Gdy pliki cookie innych firm są zablokowane, widżet nie może uzyskać dostępu do pliku cookie najwyższego poziomu, co może negatywnie wpłynąć na wrażenia użytkownika.
Gdy pliki cookie innych firm są wyłączone, widżet payment-provider.example nie będzie mieć dostępu do pliku cookie sesji użytkownika ustawionego w kontekście najwyższego poziomu w payment-provider.example.

rozwiązanie dostosowane do potrzeb klienta z FedCM,

Usługa payment-provider.example powinna rozważyć wdrożenie FedCM, aby działać jako dostawca tożsamości. To podejście może być odpowiednie, gdy:

  • payment-provider.example jest umieszczony na niezwiązanych stronach zewnętrznych.
  • payment-provider.example jest umieszczony w co najmniej 5 powiązanych witrynach.

Główną zaletą FedCM jest to, że interfejs może zapewnić użytkownikom więcej kontekstu dotyczących ich wyborów. Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną korzystającą z usługi (merchant.example) a dostawcą tożsamości (payment-provider.example). Strona korzystająca z usługi może obsługiwać co najmniej jednego dostawcę tożsamości, a interfejs FedCM będzie wyświetlany tylko warunkowo.

W zależności od potrzeb deweloperzy mogą wybrać tryb pasywny, w którym prompt FedCM pojawia się automatycznie, gdy użytkownik jest zalogowany u dostawcy tożsamości, lub tryb aktywny, w którym proces logowania powinien zostać uruchomiony po wykonaniu przez użytkownika określonego działania, np. kliknięciu przycisku płatności.

FedCM pełni też funkcję sygnału zaufania dla interfejsu Storage Access API (SAA), który umożliwia elementowi embedowanemu dostęp do niezagregowanych plików cookie najwyższego poziomu po tym, jak użytkownik wyrazi zgodę na logowanie się u dostawcy elementu embedowanego, bez konieczności wyświetlania dodatkowego prompta.

Rozwiązanie skupiające się na dostępie do pamięci

Innym interfejsem API, który warto wziąć pod uwagę, jest Storage Access API (SAA). W przypadku SAA użytkownik będzie proszony o zezwolenie na dostęp do plików cookie najwyższego poziomu w ramach usługi payment-provider.example. Jeśli użytkownik wyrazi zgodę na dostęp, formularz może się wyświetlać tak samo jak w przypadku dostępu do plików cookie innych firm.

Podobnie jak w przypadku FedCM, użytkownik będzie musiał zatwierdzić prośbę w przypadku każdej nowej witryny, w której jest umieszczony element payment-provider.example. Aby dowiedzieć się, jak działa interfejs API, obejrzyj demonstrację interfejsu SAA. Jeśli domyślny prompt SAA nie spełnia Twoich potrzeb, rozważ wdrożenie FedCM, aby uzyskać bardziej spersonalizowane rozwiązanie.

Zmniejsz utrudnienia dla użytkowników na niewielkiej liczbie powiązanych witryn

Jeśli witryna sprzedawcy i dostawca płatności należą do tej samej firmy, możesz użyć interfejsu API powiązanych zestawów witryn (RWS), aby zadeklarować relacje między domenami. Może to pomóc w zmniejszeniu trudności dla użytkowników: jeśli na przykład insurance.examplepayment-portal-insurance.example znajdują się w tym samym RWS, payment-portal-insurance.example automatycznie uzyska dostęp do własnych plików cookie najwyższego poziomu, gdy zostanie przesłane żądanie dostępu do pamięci w ramach kodu embedowanego payment-portal-insurance.example.

Inne rozwiązania eksperymentalne

Innym eksperymentalnym interfejsem API, który może być przydatny w tym scenariuszu, jest Partitioned Popins. Interfejs API jest obecnie w fazie aktywnego rozwoju.

W przypadku podzielonych popinów użytkownik może zostać poproszony o podanie danych logowania, aby zalogować się w aplikacji payment-provider.example w otwartym przez nią popinie.merchant.example Miejsce na dane zostanie partycjonowane przez osobę otwierającą merchant.example. W tym przypadku element payment-provider.example embed będzie mieć dostęp do wartości pamięci ustawionych w pop-inie. W ramach tego rozwiązania użytkownik musi zalogować się w witrynie dostawcy usług płatniczych.

Niektórzy dostawcy usług płatniczych oferują usługę generowania linku do płatności, który powoduje wyświetlenie niestandardowej strony płatności w witrynie sprzedawcy. Usługa linków do płatności i portal użytkownika dostawcy płatności są często wdrażane w różnych domenach, np. payment-provider.examplepayment-link.example.

payment-link.example umieszcza formularz płatności udostępniony przezpayment-provider.example. To jest wariant wzorca osadzonego formularza płatności. W tym przypadku warto też rozważyć FedCM, SAARWS.

Panele płatności

Niektóre aplikacje wyświetlają użytkownikom panele transakcji z różnych witryn, zapewniając im centralny widok ich działań finansowych. Wymaga to dostępu panelu do danych dotyczących użytkowników z różnych domen.

Rozważ te domeny:

  • earnings.example udostępnia panel płatności, który można umieszczać w różnych aplikacjach internetowych. Ta usługa przechowuje dane o zarobkach użytkowników i informacje o sesji.
  • catsitting.example i dogsitting.example to osobne witryny, które zawierają panel earnings.example.

Użytkownik loguje się na swoje konto earnings.example. Gdy wejdą na stronę catsitting.example lub dogsitting.example, mogą sprawdzić swoje zarobki. Wbudowany panel earnings.example korzysta z plików cookie najwyższego poziomu i wyświetla spersonalizowane informacje o zarobkach użytkownika.

Podobnie jak w innych przykładach, gdy pliki cookie innych firm są wyłączone, kod earnings.example nie będzie miał dostępu do plików cookie najwyższego poziomu.

Diagram ilustrujący scenariusz, w którym informacje o zarobkach użytkownika, hostowane na stronie earnings.example,
      są wyświetlane w osadzonym panelu na stronie dogsitting.example.  Gdy pliki cookie innych firm są zablokowane,
      wbudowany panel nie może uzyskać dostępu do pliku cookie najwyższego poziomu, co uniemożliwia wyświetlanie spersonalizowanych danych o zarobkach użytkownika.
Gdy pliki cookie innych firm są wyłączone, widżet „earnings.example” umieszczony w witrynie „dogsitting.example” nie będzie miał dostępu do pliku cookie ustawionego w kontekście najwyższego poziomu w witrynie „earnings.example”.

Panele własne

Jeśli wszystkie 3 domeny należą do tej samej strony, rozważ użycie SAA w połączeniu z RWS. Dzięki SAA usługa earnings.example może uzyskać dostęp do pliku cookie najwyższego poziomu z uprawnieniami użytkownika. Jeśli ta strona używa earnings.example w 4 lub mniej domenach, deklarowanie relacji między nimi za pomocą RWS może zapewnić płynniejsze wrażenia użytkownika.

Jeśli ta sama osoba umieszcza widżet w większej liczbie niż 5 domen, nie może deklarować relacji między wszystkimi witrynami, w których widżet jest umieszczony, a domeną widżetu, ponieważ RWS obsługuje maksymalnie 6 witryn w zbiorze: jedną główną i 5 powiązanych.

Dystrybucja paneli skalowanych

W tych przypadkach SAARWS mogą nie być optymalnym rozwiązaniem:

  • rozpowszechniasz rozwiązanie w postaci panelu dla witryn innych firm;
  • masz więcej niż 5 witryn, które zawierają widżet panelu.

W takim przypadku earnings.example powinna rozważyć wdrożenie FedCM, aby pełnić rolę dostawcy tożsamości. Oznacza to, że użytkownik musi zalogować się w systemie dogsitting.example przy użyciu konta zarządzanego przez earnings.example.

FedCM udostępnia interfejs użytkownika, który można dostosować, aby wyraźnie informować użytkowników, które informacje są udostępniane. Dzięki usłudze FedCM aplikacja dogsitting.example może poprosić aplikację earnings.example o udostępnienie specjalnych uprawnień, np. dostępu do danych o transakcjach.

FedCM pełni też funkcję znaku zaufania dla interfejsu Storage Access API, a w przypadku osadzenia earnings.example zostanie przyznany dostęp do miejsca na dane dla własnych plików cookie najwyższego poziomu bez dodatkowego pytania użytkownika podczas wywołania interfejsu SAA API.

Ustawienia panelu dotyczące witryny

Jeśli danych nie trzeba udostępniać w wielu witrynach, rozważ podzielenie plików cookie za pomocą CHIPS. Pliki CHIPS mogą być przydatne do przechowywania ustawień dotyczących konkretnych witryn, na przykład układu lub filtrów panelu.

Zarządzaj formami płatności

Innym typowym scenariuszem jest wyświetlanie i edytowanie form płatności przez użytkownika w ramach wbudowanego elementu bez konieczności opuszczania witryny hosta.

Rozważ ten proces:

  • payments.example udostępnia narzędzie do zarządzania płatnościami, które można umieszczać w witrynach. Ta usługa przechowuje dane płatności użytkownika i informacje o sesji.
  • shop.example to witryna, która zawiera narzędzie payments.example umożliwiające użytkownikom wyświetlanie, edytowanie i wybieranie preferowanych form płatności powiązanych z ich kontem shop.example.

Dostawcy usług płatniczych, którzy implementują zarządzanie formami płatności, powinni też rozważyć zostanie dostawcą tożsamości za pomocą FedCM. Dzięki FedCM użytkownik będzie mógł zalogować się na konto strony korzystającej (shop.example) za pomocą konta zarządzanego przez dostawcę tożsamości (payments.example).

Za zgodą użytkownika FedCM umożliwia udostępnianie danych niestandardowych między stroną ufającą a dostawcą tożsamości. Główną zaletą korzystania z FedCM jest to, że interfejs użytkownika może zapewnić użytkownikom więcej kontekstu dotyczącego ich wyborów. Jest on też sygnałem zaufania dla interfejsu Storage Access API, który umożliwia dostęp do plików cookie najwyższego poziomu.

Gdy pliki cookie innych firm są wyłączone, w ramach funkcji payments.example nie będzie można uzyskać dostępu do plików cookie najwyższego poziomu. W takim przypadku SAA może pomóc zapewnić prawidłowe działanie, prosząc o dostęp do pamięci masowej.

Czasami informacje zawarte w zawartym embedzie nie muszą być udostępniane innym witrynom, w których jest on umieszczony. payments.example może być konieczne przechowywanie różnych preferencji użytkowników w przypadku każdej konkretnej witryny, w której treści są umieszczane. W takim przypadku rozważ podzielenie plików cookie za pomocą CHIPS. W przypadku CHIPS plik cookie utworzony w ramach payments.example osadzonego w shop.example nie będzie dostępny dla payments.example osadzonego w another-shop.example.

Innym eksperymentalnym interfejsem API, który można potencjalnie wykorzystać w tym procesie użytkownika, jest Partitioned Popins. Gdy użytkownik zaloguje się w payments.example w wyskakującym okienku otwartym przez shop.example, miejsce na dane zostanie podzielone przez osobę, która otworzyła okno, a element payments.example wbudowany w inne aplikacje będzie mieć dostęp do wartości miejsca na dane ustawionych w wyskakującym okienku. Takie podejście wymaga jednak od użytkowników wpisywania danych logowania w przypadku każdego dostawcy usług płatniczych.

Wykrywanie oszustw

Systemy analizy ryzyka mogą analizować dane przechowywane w plikach cookie w celu identyfikowania wzorców odbiegających od normy. Jeśli na przykład użytkownik nagle zmieni adres dostawy i dokona kilku dużych zakupów za pomocą nowego urządzenia, może to zwiększyć wynik potencjalnego oszustwa. Pliki cookie służące do wykrywania oszustw to zazwyczaj pliki cookie innych firm, które są ustawiane na stronach sprzedawców przez dostawców płatności lub widżety usług zapobiegania oszustwom.

Ograniczenia plików cookie innych firm nie powinny zakłócać działania systemów wykrywania oszustw, ale mogą powodować dodatkowe problemy dla użytkowników. Jeśli system nie może z pewnością potwierdzić, że użytkownik jest autentyczny z powodu zablokowanych plików cookie, może wymagać dodatkowych kontroli, takich jak weryfikacja tożsamości.

Aby wykrywać oszustwa, gdy pliki cookie innych firm są zablokowane, rozważ zintegrowanie interfejsu Private State Tokens API (PST) z rozwiązaniem do wykrywania oszustw. Dzięki PST dostawca płatności może zarejestrować się jako wystawca tokenów i przyznawać użytkownikom tokeny, które nie są oparte na plikach cookie innych firm. Tokeny te można następnie wykorzystać na stronach sprzedawców w celu sprawdzenia, czy użytkownik jest godny zaufania. Szczegółowe informacje o wdrożeniu znajdziesz w dokumentacji dla programistów dotyczącej PST.

Piaskownica prywatności eksperymentuje z innymi interfejsami API do zwalczania oszustw.

Spersonalizowany przycisk finalizacji

Przyciski płatności (np. Zapłać za pomocą <preferowanej formy płatności>) umieszczone na stronach sprzedawców często korzystają z informacji z wielu witryn ustawionych przez dostawcę płatności. Umożliwia to personalizację, a użytkownicy mogą płacić za pomocą preferowanej formy płatności. Jeśli w przeglądarce użytkownika są zablokowane pliki cookie innych firm, może to mieć wpływ na renderowanie spersonalizowanego przycisku płatności.

Chociaż SAA może umożliwiać dostęp do pamięci, wymagany komunikat może nie zapewnić użytkownikom optymalnych wrażeń.

Rozważamy potencjalne rozwiązanie, które jest przeznaczone do tego konkretnego przypadku użycia: Fenced Frames z dostępem do lokalnych danych bez partycjonowania. Interfejs API jest obecnie w aktywnej fazie rozwoju, a Ty możesz mieć wpływ na jego przyszłość. Wypróbuj to samodzielnie i przekaż opinię.

Pomoc

Zgłaszaj awarie na stronie goo.gle/report-3pc-broken. Możesz też przesłać formularz opinii lub zgłosić problem w GitHub w repozytorium pomocy dla deweloperów dotyczącej Piaskownicy prywatności.