Controllare l'impatto delle modifiche ai cookie di terze parti sui flussi di lavoro dei pagamenti

Chrome propone una nuova esperienza per la scelta dell'utente in merito ai cookie di terze parti. Devi preparare il tuo sito per gli utenti che scelgono di navigare senza cookie di terze parti.

Questa pagina contiene informazioni su cosa potrebbe essere interessato dalle imminenti modifiche.

Percorsi comuni degli utenti

Molti flussi di lavoro di pagamento e acquisto si basano su cookie di terze parti. La tabella seguente elenca alcuni percorsi utente che potrebbero essere interessati se i cookie di terze parti vengono disattivati e suggerisce API alternative che gli sviluppatori possono utilizzare per evitare interruzioni. Questo elenco potrebbe non essere esaustivo e potrebbe essere aggiornato man mano che diventano disponibili altre soluzioni di Privacy Sandbox. Ti invitiamo a condividere il tuo feedback se riscontri altri scenari interessati.

Il modo migliore per verificare se i flussi utente sono interessati dalle limitazioni dei cookie di terze parti è esaminarli con l'indicatore di test dei cookie di terze parti abilitato.

Per assicurarti che il tuo sito web funzioni come previsto, testa il seguente flusso con i cookie di terze parti limitati:

  • Pagamento su più siti: testa i flussi di pagamento che si basano su un fornitore di servizi di pagamento di terze parti (ad esempio Paga con <example-provider>). Assicurati che:
    • Il reindirizzamento viene eseguito correttamente.
    • Il gateway di pagamento viene caricato correttamente.
    • La procedura di pagamento può essere completata senza errori.
    • L'utente viene reindirizzato al tuo sito web come previsto.
  • Dashboard dei pagamenti: verifica che i widget della dashboard delle transazioni funzionino come previsto con i cookie di terze parti limitati. Verifica che l'utente possa:
    • Accedi alla dashboard.
    • Visualizza tutti i pagamenti come previsto.
    • Navigare senza errori tra le diverse sezioni della dashboard (ad es. cronologia transazioni, dettagli pagamento).
  • Gestisci metodi di pagamento: verifica che i widget di gestione dei metodi di pagamento funzionino come previsto. Con i cookie di terze parti bloccati, verifica che:
    • L'aggiunta o l'eliminazione di un metodo di pagamento funziona come previsto.
    • Il pagamento con i metodi di pagamento salvati in precedenza non è interessato.
  • Rilevamento delle attività fraudolente: confronta il funzionamento della tua soluzione di rilevamento delle attività fraudolente con e senza cookie di terze parti.
    • Il blocco dei cookie di terze parti introduce passaggi aggiuntivi, provocando ulteriore attrito per gli utenti?
    • Può comunque rilevare modelli sospetti quando i cookie di terze parti sono bloccati nel browser?
  • Pulsante di pagamento personalizzato: verifica se i pulsanti di pagamento vengono visualizzati correttamente con i cookie di terze parti limitati.
    • L'utente può comunque completare gli acquisti anche se il pulsante personalizzato non mostra il suo metodo preferito?

Pagamenti cross-site

Alcuni fornitori di servizi di pagamento potrebbero fare affidamento su cookie di terze parti per consentire agli utenti di accedere al loro account su più siti di commercianti senza dover eseguire nuovamente l'autenticazione. Questo percorso dell'utente potrebbe essere interessato per chi sceglie di navigare senza cookie di terze parti.

Moduli di pagamento incorporati

Considera i seguenti domini:

  • payment-provider.example fornisce servizi di pagamento ai siti dei commercianti e memorizza i dati di pagamento e sessione degli utenti.
  • merchant.example è un sito web che incorpora un modulo di pagamento fornito da payment-provider.example.

Un utente ha appena eseguito l'accesso a payment-provider.example (ad esempio, mentre completa il pagamento su un altro sito). L'utente avvia una procedura di pagamento su merchant.example.

Se sono disponibili cookie di terze parti, il modulo di pagamento di payment-provider.example incorporato in merchant.example avrebbe accesso al proprio cookie di sessione di primo livello impostato su payment-provider.example nel contesto di primo livello. Tuttavia, se i cookie di terze parti sono bloccati, l'embed non avrà accesso ai propri cookie di primo livello.

Il diagramma mostra un&#39;interazione con il sito web di un commerciante (merchant.example) che utilizza un widget di pagamento di un fornitore di terze parti (payment-provider.example). Quando i cookie di terze parti sono bloccati, il widget non può accedere al proprio cookie di primo livello, il che potrebbe interrompere l&#39;esperienza dell&#39;utente.
Quando i cookie di terze parti sono disabilitati, il widget "payment-provider.example" non avrà accesso al cookie della sessione utente impostato nel contesto di primo livello su "payment-provider.example".

Una soluzione personalizzabile con FedCM

payment-provider.example dovrebbe valutare la possibilità di implementare FedCM per fungere da un provider di identità. Questo approccio può essere adatto quando:

  • payment-provider.example è incorporato in siti di terze parti non correlati.
  • payment-provider.example è incorporato in più di cinque siti correlati.

Il vantaggio principale di FedCM è che l'interfaccia utente può fornire agli utenti più contesto per le loro scelte. Con l'autorizzazione dell'utente, FedCM consente la condivisione di dati personalizzati tra la Relying Party (merchant.example) e l'Identity Provider (payment-provider.example). La Relying Party può scegliere di supportare uno o più Identity Provider e l'interfaccia utente di FedCM verrà visualizzata solo condizionatamente.

A seconda delle esigenze, gli sviluppatori possono scegliere tra la modalità passiva, in cui la richiesta di FedCM viene visualizzata automaticamente quando l'utente accede con l'identity provider, o la modalità attiva, in cui la procedura di accesso deve essere attivata dopo un'azione dell'utente, ad esempio il clic su un pulsante di pagamento.

FedCM funge anche da indicatore di attendibilità per l'API Storage Access (SAA), che consente all'embed di accedere ai suoi cookie non partizionati di primo livello dopo che l'utente accetta di accedere con il provider dell'embed, senza bisogno di un prompt aggiuntivo per l'utente.

Soluzione incentrata sull'accesso allo spazio di archiviazione

Un'altra API da prendere in considerazione è l'API Storage Access (SAA). Con l'ASA, all'utente verrà chiesto di consentire all'embedding di payment-provider.example di accedere ai propri cookie di primo livello. Se l'utente approva l'accesso, il modulo può essere visualizzato come quando sono disponibili i cookie di terze parti.

Come per FedCM, l'utente dovrà approvare la richiesta su ogni nuovo sito in cui è incorporato payment-provider.example. Guarda la demo di SAA per capire come funziona l'API. Se il prompt SAA predefinito non soddisfa le tue esigenze, ti consigliamo di implementare FedCM per un'esperienza più personalizzata.

Ridurre le difficoltà degli utenti su un numero limitato di siti correlati

Se sia il sito del commerciante sia il fornitore di servizi di pagamento appartengono alla stessa azienda, puoi utilizzare l'API Related Website Sets (RWS) per dichiarare le relazioni tra i domini. In questo modo, puoi ridurre le difficoltà degli utenti: ad esempio, se insurance.example e payment-portal-insurance.example si trovano nella stessa RWS, payment-portal-insurance.example avrà automaticamente accesso ai propri cookie di primo livello quando viene richiesto l'accesso allo spazio di archiviazione all'interno del payment-portal-insurance.example incorporato.

Altre soluzioni sperimentali

Un'altra API sperimentale che potrebbe essere utile in questo scenario è Partitioned Popins. L'API è attualmente in fase di sviluppo attivo.

Con i popup suddivisi, all'utente può essere chiesto di inserire le proprie credenziali per accedere a payment-provider.example in un popup aperto da merchant.example. Lo spazio di archiviazione verrà partizionato dall'aprifile merchant.example. In questo caso, l'embed payment-provider.example avrà accesso ai valori di archiviazione impostati nel popup. Con questa soluzione, l'utente dovrà accedere al fornitore di servizi di pagamento su ogni sito.

Alcuni fornitori di servizi di pagamento offrono un servizio che genera un link di pagamento, che mostra una pagina di pagamento personalizzata per il sito di un commerciante. Un servizio di collegamento dei pagamenti e un portale utente per il fornitore di servizi di pagamento vengono spesso implementati in domini diversi, ad esempio payment-provider.example e payment-link.example.

payment-link.example incorpora un modulo di pagamento fornito da payment-provider.example. Si tratta di una variante del pattern modulo di pagamento incorporato. Anche FedCM, SAA e RWS sono ottime opzioni da prendere in considerazione per questo caso.

Dashboard pagamenti

Alcune applicazioni mostrano ai propri utenti dashboard delle transazioni su più siti, fornendo una visione centralizzata delle loro attività finanziarie. Per questo, la dashboard deve accedere ai dati specifici degli utenti in più domini.

Considera i seguenti domini:

  • earnings.example fornisce una dashboard dei pagamenti che può essere incorporata in varie applicazioni web. Questo servizio memorizza i dati sugli utili degli utenti e le informazioni sulle sessioni.
  • catsitting.example e dogsitting.example sono siti web distinti che incorporano entrambi la dashboard earnings.example.

Un utente accede al proprio account earnings.example. Quando visitano catsitting.example o dogsitting.example, possono visualizzare i propri utili. La dashboard earnings.example incorporata si basa sui cookie di primo livello e mostra le informazioni personalizzate sugli utili dell'utente.

Come in altri esempi, l'embed di earnings.example non avrà accesso ai suoi cookie di primo livello se i cookie di terze parti sono disattivati.

Diagramma che illustra uno scenario in cui le informazioni sugli utili di un utente, ospitate su earnings.example,
      vengono visualizzate in una dashboard incorporata su dogsitting.example.  Quando i cookie di terze parti sono bloccati,
      la dashboard incorporata non può accedere al proprio cookie di primo livello, impedendo la visualizzazione dei dati sugli utili personalizzati dell&#39;utente.
Quando i cookie di terze parti sono disattivati, il widget "earnings.example" incorporato in "dogsitting.example" non avrà accesso al cookie impostato nel contesto di primo livello su "earnings.example".

Dashboard proprietarie

Se tutti e tre i domini appartengono alla stessa parte, ti consigliamo di utilizzare SAA insieme a RWS. Con l'autorizzazione dell'utente, earnings.example può accedere al proprio cookie di primo livello con l'autorizzazione dell'utente. Se questa parte utilizza earnings.example su quattro o meno domini, la dichiarazione delle relazioni tra questi con RWS può offrire un'esperienza utente più scorrevole.

Se la stessa parte incorpora il widget in più di cinque domini, non può dichiarare relazioni tra tutti i siti di incorporamento e il dominio del widget, poiché RWS supporta solo sei siti in un insieme: uno principale e cinque associati.

Distribuzione delle dashboard su larga scala

Nei seguenti casi, SAA e RWS potrebbero non essere la soluzione ottimale:

  • Distribuisci una soluzione di dashboard per siti di terze parti.
  • Hai più di cinque siti che incorporano il widget della dashboard.

In questo caso, earnings.example dovrebbe prendere in considerazione l'implementazione di FedCM come provider di identità. Ciò significa che l'utente dovrà accedere a dogsitting.example con un account gestito da earnings.example.

FedCM offre un'interfaccia utente personalizzabile che può aiutare a comunicare chiaramente all'utente quali informazioni vengono condivise. Con FedCM, dogsitting.example può richiedere earnings.example di condividere autorizzazioni personalizzate, ad esempio per accedere ai dati sulle transazioni.

FedCM funge anche da indicatore di attendibilità per l'API Accesso allo spazio di archiviazione, e all'embed di earnings.example verrà concesso l'accesso allo spazio di archiviazione per i suoi cookie di primo livello senza un'ulteriore richiesta all'utente nella chiamata dell'API SAA.

Impostazioni della dashboard specifiche del sito

Se i dati non devono essere condivisi su più siti, valuta la possibilità di suddividere i cookie con CHIPS. I CHIP possono essere utili per memorizzare preferenze specifiche del sito, ad esempio il layout della dashboard o i filtri.

Gestisci i metodi di pagamento

Un altro flusso comune è che l'utente possa visualizzare e modificare i propri metodi di pagamento all'interno di un'integrazione senza uscire dal sito host.

Considera il seguente flusso:

  • payments.example fornisce uno strumento di gestione dei pagamenti che può essere incorporato nei siti web. Questo servizio memorizza i dati di pagamento e le informazioni sulla sessione dell'utente.
  • shop.example è un sito web che incorpora lo strumento payments.example per consentire agli utenti di visualizzare, modificare o scegliere i metodi di pagamento preferiti associati al loro account shop.example.

I fornitori di servizi di pagamento che implementano la gestione dei metodi di pagamento dovrebbero anche considerare la possibilità di diventare fornitori di servizi di identità con FedCM. Con FedCM, l'utente potrà accedere alla terza parte attendibile (shop.example) utilizzando l'account gestito dal provider di identità (payments.example).

Con l'autorizzazione dell'utente, FedCM consente la condivisione di dati personalizzati tra la relying party e l'identity provider. Il vantaggio principale dell'utilizzo di FedCM è che l'interfaccia utente può fornire agli utenti più contesto per le loro scelte. Inoltre, funge da indicatore di attendibilità per l'API Storage Access, che consente all'embed di accedere ai suoi cookie di primo livello.

Con i cookie di terze parti disattivati, l'embed di payments.example non avrà accesso ai suoi cookie di primo livello. In questo caso, SAA può contribuire a garantire il corretto funzionamento richiedendo l'accesso allo spazio di archiviazione.

A volte le informazioni impostate all'interno dell'embed non devono essere condivise su altri siti che lo incorporano. payments.example potrebbe dover memorizzare solo preferenze degli utenti diverse per ogni sito di incorporamento specifico. In questo caso, valuta la possibilità di suddividere i cookie utilizzando CHIPS. Con CHIPS, il cookie impostato in payments.example incorporato in shop.example non sarà accessibile da payments.example incorporato in another-shop.example.

Un'altra API sperimentale che può essere potenzialmente utilizzata in questo flusso utente è Popup suddivisi. Quando l'utente accede a payments.example in un popup aperto da shop.example, lo spazio di archiviazione verrà partizionato da chi ha aperto il popup e il embed avrà accesso ai valori dello spazio di archiviazione impostati nel popup.payments.example Tuttavia, questo approccio richiede agli utenti di inserire le credenziali per accedere al fornitore di servizi di pagamento su ogni sito.

Rilevamento di frodi

I sistemi di analisi del rischio possono analizzare i dati memorizzati nei cookie per identificare modelli che si discostano dalla norma. Ad esempio, se un utente cambia improvvisamente il proprio indirizzo di spedizione ed effettua diversi acquisti di importo elevato utilizzando un nuovo dispositivo, il punteggio di potenziale attività fraudolenta potrebbe aumentare. I cookie per il rilevamento delle attività fraudolente sono solitamente cookie di terze parti, impostati sui siti dei commercianti da fornitori di servizi di pagamento o widget di servizi di prevenzione delle attività fraudolente.

Sebbene le limitazioni dei cookie di terze parti non debbano compromettere i sistemi di rilevamento delle attività fraudolente, potrebbero creare ulteriori difficoltà per gli utenti. Se il sistema non riesce a verificare con certezza che un utente è legittimo a causa dei cookie bloccati, potrebbe richiedere controlli aggiuntivi, come la verifica dell'identità.

Per supportare il rilevamento delle attività fraudolente quando i cookie di terze parti sono bloccati, valuta la possibilità di integrare l'API Private State Tokens (PST) nella tua soluzione di rilevamento delle attività fraudolente. Con la PST, un fornitore di servizi di pagamento può registrarsi come emittente di token e concedere agli utenti token che non si basano su cookie di terze parti. Questi token possono essere utilizzati sui siti dei commercianti per verificare se l'utente è affidabile. Per i dettagli sull'implementazione, consulta la documentazione per gli sviluppatori di PST.

Privacy Sandbox sta conducendo esperimenti con altre API antifrode.

Pulsante di pagamento personalizzato

I pulsanti di pagamento (ad esempio Paga con <metodo di pagamento preferito>) incorporati sui siti dei commercianti spesso si basano su informazioni cross-site impostate dal fornitore di servizi di pagamento. In questo modo è possibile personalizzare l'esperienza e gli utenti possono effettuare un pagamento agevole con il metodo che preferiscono. Se i cookie di terze parti sono bloccati nel browser dell'utente, questo può influire sul rendering del pulsante di pagamento personalizzato.

Anche se SAA potrebbe consentire l'accesso allo spazio di archiviazione, la richiesta obbligatoria potrebbe non portare a un'esperienza dell'utente ideale.

Stiamo valutando una potenziale soluzione che abbia come target specifico questo caso d'uso: Frame delimitati con accesso ai dati locali non partizionati. L'API è attualmente in una fase di sviluppo attiva e puoi dare forma al suo futuro. Prova tu stesso e fornisci feedback.

Ricevi assistenza

Segnala eventuali malfunzionamenti all'indirizzo goo.gle/report-3pc-broken. Puoi anche compilare un modulo di feedback o segnalare un problema su GitHub nel repository di assistenza per gli sviluppatori di Privacy Sandbox.