Flusso utente dell'associazione

Panoramica

Lo scopo del flusso di associazione è stabilire un token di lunga durata (noto anche come identificatore opaco) che sia l'integratore dei pagamenti (l'azienda che configura la propria forma di pagamento all'interno del nostro sistema) sia Google concordano che rappresenti il collegamento tra l'account utente di Google e l'account utente dell'integratore. Questo token di lunga durata è noto come token di Google Payments (GPT). Uno strumento consente di pagare servizi e beni all'interno dei vari ecosistemi e marketplace di Google. Un cliente Google può avere più di uno strumento.

Come funziona il flusso

  1. Google negozia un token per rappresentare un collegamento tra il cliente di Google e l'account utente dell'integratore.
  2. Google raccoglie le informazioni necessarie per la prima configurazione per creare e stabilire l'GPT.

La prova dell'identità e dell'autenticazione deve essere innanzitutto stabilita tramite il flusso di autenticazione. L'output del flusso di autenticazione viene passato al metodo associateAccount. Il flusso di associazione assocerà quindi l'account utente Google allo strumento Google. In questo modo lo strumento viene configurato in modo da poterlo utilizzare per i pagamenti.

Di seguito è riportato un diagramma che descrive in dettaglio il flusso dell'associazione:

Diagramma di sequenza di flusso dell'associazione

Diagramma di flusso dell'associazione

Ecco un elenco degli oggetti e di ciò che rappresentano:

  • Utente: si tratta della persona che vuole aggiungere un metodo di pagamento al proprio Account Google.
  • UI di Google: l'interfaccia di Google in cui il cliente inizia a configurare un metodo di pagamento.
  • UI di integrazione dei pagamenti: l'interfaccia dell'integratore (web o Android) a cui il cliente ha accesso per quell'account.
  • Server di Google: i server di backend di Google che eseguono i controlli di autenticazione e associano l'account di integratore dell'utente a un GPT (token di pagamento di Google).
  • Server integratore dei pagamenti: il server di backend dell'integratore in cui l'utente ha un account.

Si tratta di un flusso di associazione, in cui l'Account Google dell'utente viene collegato tramite un token Google al suo account di integratore. Ecco come funziona questo flusso.

  1. L'utente avvia il flusso nell'interfaccia utente di Google (ad esempio in un'interfaccia web o dell'app).
  2. La UI di Google invia un messaggio al server di Google per inviargli una richiesta di autenticazione (Request Authentication Data).
  3. Il server di Google invia una richiesta di autenticazione (authenticationRequest) alla UI di Google.
  4. La UI di Google collega l'utente alla UI dell'integratore dei pagamenti (authenticationRequest).
  5. All'utente verranno chieste identità e credenziali.
  6. La UI dell'integratore dei pagamenti invia la risposta al server dell'integrazione dei pagamenti.
  7. Il server dell'integrazione dei pagamenti autentica la risposta e invia la risposta di autenticazione (authenticationResponse) alla UI dell'integratore dei pagamenti.
  8. Questa risposta di autenticazione viene inoltrata alla UI Google.
  9. La UI di Google invia un messaggio al server di Google per verificare la risposta dell'integratore (configurazione dello strumento utente).
  10. Il server di Google convalida la risposta verificando la firma, quindi associa l'account dell'utente all'integratore dei pagamenti con un GPT e un ID associazione (authenticationRequestID, associationID) presso Google.
  11. Al server di Google viene inviato un messaggio di conferma della riuscita dell'operazione.
  12. Viene inviato un messaggio di operazione riuscita all'interfaccia utente di Google.
  13. Viene inviato un messaggio che indica che lo strumento è pronto all'uso.

Best practice e altre considerazioni

Strumenti multipli

L'integratore deve consentire l'associazione di molti GPT all'account dell'integratore di un singolo utente. Ad esempio, questa operazione è necessaria se un utente elimina il proprio strumento e crea un nuovo strumento con lo stesso account utente dell'integratore.

È possibile che due clienti Google vengano associati all'account di integrazione dello stesso utente. In questo caso, a ogni utente corrisponde uno strumento diverso. Per ogni strumento esiste un flusso di associazione indipendente e un GPT univoco.

Misure di sicurezza

Se l'integratore ritiene che ci sia stata una perdita di controllo sull'account di un integratore utente, è possibile rifiutare nuove associazioni per quell'account e gli strumenti esistenti già associati potrebbero restituire codici di rifiuto durante acquisti futuri.

Durata di GPT

Il GPT è pensato per durare a lungo e per impostazione predefinita non ha scadenza. Google consiglia vivamente un GPT senza scadenza. Ciò consente un'esperienza di acquisto ininterrotta da parte dell'utente.

Per gli integratori che non possono supportare un token senza scadenza, l'integratore può fornire la scadenza tramite il campo tokenExpirationTime del metodo associateAccount. Quando un token sta per scadere, Google invia all'utente il flusso del token di aggiornamento per estenderne la durata.

Altri identificatori

Esistono altri identificatori, oltre a GPT, che vengono scambiati durante l'associazione. Di seguito è riportato un elenco con link a ulteriori informazioni.

  • AssociationId: un token pubblico, definito da Google, che identifica l'associazione tra l'account del cliente su Google e lo strumento. Mentre GPT viene utilizzato solo nelle richieste server-server, AssociationId è l'equivalente client. Consulta la voce del glossario per ulteriori informazioni.
  • AccountId: Un identificatore definito dal fornitore (spesso un numero di account), utilizzato per scoprire le frodi e comprendere le relazioni con gli account. Anche gli agenti Google per le operazioni con i clienti lo utilizzano per identificare e poi aiutare a diagnosticare i problemi dei clienti. Consulta la voce del glossario per ulteriori informazioni.
  • AccountNickname (o fullAccountNickname): una stringa utilizzata dai fornitori per identificare i propri clienti. Viene utilizzato anche per scopi di visualizzazione. AccountNickname è mascherato dal fornitore per motivi di SPII, mentre fullAccountNickname non è mascherato.