Pagamenti standard di Google:

FOP tokenizzata

Panoramica

Una forma di pagamento tokenizzata è un tipo di integrazione di pagamento nella piattaforma Payments. Affinché un utente possa effettuare un pagamento con questa forma di pagamento, Google e l'integratore dei pagamenti devono eseguire uno scambio una tantum di credenziali di identità dell'account. A sua volta, ciò passa attraverso il flusso di definizione di un token, che rappresenta quella forma di pagamento per quel particolare utente. Questo token può quindi essere utilizzato per pagamenti ripetuti. Attualmente esistono due versioni di queste API. La versione 2 supporta gli operatori di telefonia mobile e i fornitori di numeri di riferimento. Tutti gli altri provider FOP tokenizzati devono implementare la versione 1. Il resto di questo documento è incentrato sulla versione 1.

Google utilizza due flussi per stabilire l'identità e creare questo token:

1. Flusso di autenticazione: identifica e verifica (autentica) l'utente.
2. Flusso di associazione: stabilisce un token per un utente (nuovo o identificato in precedenza e autenticato). Questo token rappresenta una particolare forma di pagamento da parte di un determinato utente. Il token potrà quindi essere utilizzato per acquisti futuri.

Una volta creato il token, Google lo utilizzerà durante il flusso di acquisto per offrire all'utente un'esperienza di pagamento rapida e fluida. Google utilizza questo token per rappresentare un'istanza di un metodo di pagamento di un cliente. Questo è anche chiamato strumento. Un cliente Google potrebbe disporre di più strumenti per pagare beni e servizi.

Infine, tutti i trasferimenti di denaro tra la banca dell'integratore e la banca di Google avvengono nell'ambito del flusso di versamenti.

1) L'utente seleziona un prodotto da acquistare

2) Dopodiché, seleziona un metodo di pagamento

3) Adesso aggiunge un nuovo metodo di pagamento

4) Vengono reindirizzati all'autenticazione

5) Infine, sono autenticati e possono acquistare

Questo diagramma illustra un'ampia panoramica dei flussi:

Panoramica della FOP tokenizzata

A livello generale, l'aggiunta del servizio come forma di pagamento ai prodotti Google prevede i seguenti flussi:

1. Flusso di autenticazione
2. Flusso di associazioni
3. Flusso di acquisto
4. Flusso di rimborso
5. Flusso di versamento

Questi flussi sono descritti in modo più dettagliato nelle sezioni seguenti e in modo ancora più dettagliato nella sezione guide.

Concetti e terminologia

Simboli e Convenzioni

Le parole chiave "DEVE", "NON DEVE" "OBBLIGATORIO", "SHALL" "NON DEVE" "DOVREBBE" "NON DOVREBBE" "CONSIGLIATO" "MAGGIO", e "OPTIONAL" in questi documenti devono essere interpretati come descritto in RFC 2119.

Timestamp

Tutti i timestamp sono rappresentati in millisecondi dall'epoca di Unix (1° gennaio 1970) in UTC.

Ad esempio:

• 23 aprile 2019 20:23:25 GMT = 1556051005000 millisecondi
• 16 agosto 2018 12:28:35 GMT = 1534422515000 millisecondi

Importi

I valori monetari in questa API sono nel formato "micro", uno standard offerto da Google. I micro sono un formato a precisione fissa basato su numeri interi. Per rappresentare un valore monetario in micro, moltiplica il valore della valuta standard per 1.000.000.

Ad esempio:

• 1,23$= 1230.000 micro USD
• 0,01$= 10.000 micro USD

Idempotenza

Tutte le chiamate al metodo all'interno di questa API devono avere un comportamento idempotente. Google riproverà sporadicamente le richieste per garantire che le transazioni siano nello stesso stato su entrambe le parti. Gli integratori non devono tentare di rielaborare richieste già elaborate correttamente. Dovrebbe invece essere segnalata la risposta per l'elaborazione riuscita. Tutti i metodi hanno un elemento RequestHeader comune che contiene un requestId. Questo requestId è la chiave di idempotenza per tutte le chiamate.

Qualsiasi risposta senza terminale (non HTTP 200-success) non deve essere elaborata in modo idempotente. Di conseguenza, una richiesta che in precedenza ha ricevuto un 400 (richiesta errata/precondizione non riuscita), quando viene chiamata una seconda volta, non deve restituire idempotentemente 400 e deve essere rivalutata. Alla nuova valutazione, potrebbe restituire un errore 400 o essere elaborato correttamente.

Per ulteriori informazioni sull'idempotenza, consulta questa guida dettagliata.

Integratore

Una società che utilizza la piattaforma di pagamento di Google per la propria attività. Potrebbe trattarsi di un'attività interna, ad esempio YouTube o AdWords, o di un'attività di terze parti che vuole integrare il proprio servizio in modo che funzioni con l'ecosistema di Google.

forma di pagamento

Forma di pagamento. È più generico di uno strumento. Visa, MasterCard e PayPal sono tutte forme di forma di pagamento.

Strumento

Un'istanza particolare di una forma di pagamento da parte di un cliente specifico. ad esempio la carta di credito o l'account PayPal di un utente. Anche una forma di pagamento tokenizzata per un determinato cliente è uno strumento, in quanto è un'istanza di una forma di pagamento per il cliente in questione, memorizzata in modo sicuro nel nostro sistema.

Token

La rappresentazione sul sistema di Google del metodo di pagamento di uno specifico utente. Poiché contiene tutte le informazioni necessarie per effettuare un acquisto, anche un token è uno strumento. Potrebbero essere incluse informazioni quali il numero di conto bancario di un utente presso il proprio integratore.

Flussi chiave

Flusso di autenticazione

L'autenticazione è il primo flusso che deve avvenire. Lo scopo del flusso di autenticazione è identificare e autenticare l'utente nell'integratore. L'autenticazione può avvenire in vari modi. Le forme di pagamento tokenizzate supportano due modi per identificare e autenticare l'utente:

1. Autenticazione OTP tramite SMS-MT (SMS da dispositivo mobile terminato, password monouso)
2. Autenticazione di reindirizzamento

Durante l'onboarding, gli integratori collaborano con Google per scegliere i meccanismi di autenticazione più adatti al loro prodotto.

I flussi di autenticazione possono essere utilizzati in due contesti: prima per identificare un nuovo cliente per creare un'associazione e per richiedere a un utente le credenziali di uno strumento esistente. Il risultato del flusso di autenticazione può essere utilizzato come input per più flussi, ad esempio il flusso di associazione, il flusso del token di aggiornamento, il flusso di acquisto con challenge e così via. Inoltre, il flusso di autenticazione può essere utilizzato in modalità autonoma, non legato a nessun flusso successivo.

Autenticazione OTP SMS-MT

In questo meccanismo di autenticazione, l'utente inserisce un numero di telefono in una UI di Google. Google invia questo numero di telefono all'integratore (tramite il metodo sendOtp). L'integratore invia una password monouso all'utente. L'utente inserisce la password nell'UI di Google che la invia all'integratore. Questo attiva una risposta positiva da parte dell'integratore pagamenti.

Quando l'autenticazione OTP tramite SMS-MT viene utilizzata in modalità autonoma, il valore dell'OTP viene inviato all'integratore utilizzando il metodo verifyOtp. Questo metodo verifica che l'OTP fornita sia quella inviata.

Autenticazione di reindirizzamento

L'autenticazione di reindirizzamento avviene quando Google reindirizza l'utente a un'applicazione di proprietà dell'integratore. Potrebbe trattarsi di un'applicazione web o per Android.

I reindirizzamenti di Android e quelli web si comportano in modo simile. Google reindirizza l'utente all'app dell'integratore. L'integratore identifica e autentica l'utente nella forma più naturale per quell'integratore. Una volta autenticato, l'integratore reindirizza l'utente all'interfaccia utente di Google per completare l'associazione. Al momento del reindirizzamento, Google fornisce un elemento requestId per identificare questa sessione di autenticazione. L'identificatore viene quindi utilizzato come prova di identità per l'autenticazione durante l'associazione.

Gli integratori che scelgono questo flusso devono fornire un URL di autenticazione web, poiché questo è il denominatore più comune in tutte le piattaforme (computer o dispositivi mobili). Tuttavia, è vivamente consigliata l'autenticazione Android per garantire la migliore esperienza utente sui dispositivi mobili.

A seconda del contesto del dispositivo e delle app installate, le UI di Google sceglieranno il reindirizzamento web o dell'app per Android.

Questo meccanismo di autenticazione offre la massima libertà all'integratore. Esistono molti modi per autenticare e identificare un utente. Nome utente e password o informazioni biometriche e domande di sicurezza sono entrambe soluzioni attuabili. Google non intende dettare il modo in cui un integratore verifica un utente. L'integratore si occupa di autenticare l'utente. In questo modo, Google intende sfruttare le varie interfacce utente dell'integratore per autenticare l'utente e fornire semplicemente a Google una prova di autenticazione.

Nota: se l'integratore utilizzerà la OTP SMS-MT durante il reindirizzamento, Google consiglia vivamente di sfruttare la già citata autenticazione OTP SMS-MT. Offrono all'utente un'esperienza più fluida sulle proprietà di Google.

Per ulteriori informazioni sull'autenticazione, consulta questa guida dettagliata.

Flusso di associazione

Dopo il flusso di autenticazione tramite uno dei meccanismi sopra menzionati, l'utente passa al flusso di associazione. Lo scopo del flusso di associazione è creare un token di pagamento Google (GPT) per creare uno strumento. Questo flusso effettua le seguenti operazioni:

1. Negozia un'identità denominata token per rappresentare l'utente.
2. Fornisce informazioni sull'account per fornire informazioni al motore di ricerca del rischio di Google.
3. Raccoglie le informazioni necessarie per la configurazione iniziale per creare e stabilire GPT.

Il risultato è che il GPT stabilito viene concordato sia da Google che dall'integratore.

Due utenti Google possono condividere lo stesso account utente con l'integratore. In questo caso, ogni utente avrà uno strumento diverso. Per ogni strumento c'è un flusso di associazione indipendente e, di conseguenza, un GPT univoco.

Questa illustrazione ti guiderà attraverso una falsa forma di pagamento tokenizzata chiamata InvisiCash. Questo mostra i passaggi che un utente dovrà eseguire per il flusso di autenticazione e il flusso di associazione.

Panoramica del flusso di associazione

1. Un utente Google con l'indirizzo email [e-mail] vuole aggiungere il suo account InvisiCash al Google Play Store per poterlo utilizzare per gli acquisti.
2. Il Google Play Store apre l'app InvisiCash per l'autenticazione.

3. L'utente accede al suo account InvisiCash con l'indirizzo e-mail [e-mail]. Forse utilizza il suo indirizzo email Gmail per entrambi, se questi sono i suoi dati di accesso per il suo account InvisiCash.

   Nota: esistono altri modi di autenticazione. Questo è solo un esempio. Potrebbe anche essere fatto sul web anziché tramite un'app.

4. L'app InvisiCash restituisce l'ID di autenticazione al Google Play Store.

5. Il Google Play Store invia l'ID di autenticazione ai server di Google.

6. Il server di Google invia un messaggio al server InvisiCash per associare l'account. Questa associazione include un ID autenticazione, GPT (token di pagamento Google) e un ID associazione.

7. I server di InvisiCash archiviano il token di pagamento Google (GPT) e l'ID di associazione. Entrambi sono ora associati all'account InvisiCash di Sally.

8. InvisiCash approva questa associazione. I Server di Google creano quindi uno strumento che può essere utilizzato per acquisti futuri.