Pagamenti standard di Google:

FOP tokenizzata

Panoramica

Una forma di pagamento tokenizzata è un tipo di integrazione dei pagamenti nella Piattaforma di pagamento. Affinché un utente possa effettuare un pagamento con questa forma di pagamento, Google e l'integratore dei pagamenti devono effettuare uno scambio una tantum delle credenziali di identità dell'account. Questo a sua volta passa attraverso la procedura di impostazione di un token, che rappresenta la forma di pagamento per l'utente specifico. Questo token può quindi essere utilizzato per pagamenti ripetuti. Al momento sono disponibili 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. La parte rimanente di questo documento è incentrata 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 e autenticato in precedenza). Questo token rappresenta una particolare forma di pagamento da parte di un determinato utente. Il token potrebbe quindi essere utilizzato per acquisti futuri.

Una volta stabilito il token, Google lo utilizzerà durante il flusso di acquisto per offrire all'utente un'esperienza di pagamento rapida e senza interruzioni. Google utilizza questo token per rappresentare un'istanza di un metodo di pagamento da parte di un cliente. Questo strumento è anche chiamato strumento. Un cliente Google può disporre di più di uno strumento per pagare beni e servizi.

Infine, tutti i movimenti di denaro tra la banca dell'integratore e la banca di Google avvengono nel flusso di pagamento.

1) L'utente seleziona un prodotto da acquistare

2) Quindi, seleziona un metodo di pagamento

3) Ora 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 forma di pagamento tokenizzata

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

1. Flusso di autenticazione
2. Flusso di associazione
3. Flusso di acquisto
4. Procedura di rimborso
5. Flusso di pagamento

Questi flussi sono descritti in maggiore dettaglio nelle sezioni di seguito e in maggiore dettaglio nella sezione Guide.

Concetti e terminologia

Simboli e convenzioni

Le parole chiave "DEVE", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questi documenti devono essere interpretate come descritto nel documento RFC 2119.

Timestamp

Tutti i timestamp sono rappresentati in millisecondi dall'epoca Unix (1 gennaio 1970) nel fuso orario 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 in un formato chiamato "micros", uno standard di 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 USD = 1230000 micro USD
• 0,01$= 10.000 micro USD

Idempotenza

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

Qualsiasi risposta non terminale (un errore HTTP 200 con esito positivo) non deve essere elaborata in modo idempotente. Pertanto, una richiesta che in precedenza riceveva un valore 400 (precondizione errata/non valida), quando chiamata una seconda volta, non deve restituire idempotentemente 400, deve essere rivalutata. Al momento della nuova valutazione, potrebbe restituire un valore 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à. Può essere un'azienda interna (1P), come YouTube o AdWords, o anche un'attività esterna (3P) che vuole integrare il proprio servizio per funzionare con l'ecosistema di Google.

FOP

Forma di pagamento. Questa procedura è più generica rispetto a uno strumento. Visa, MasterCard e PayPal sono tutte forme di pagamento.

Strumento

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

Token

Una rappresentazione, sul sistema di Google, del metodo di pagamento di un utente specifico. Poiché contiene tutte le informazioni necessarie per effettuare un acquisto, anche il token è uno strumento. Ciò può includere informazioni quali il numero di account che un utente ha presso il suo integratore.

Flussi principali

Flusso di autenticazione

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

1. Autenticazione SMS-MT OTP (SMS mobile terminato, password monouso)
2. Autenticazione 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: primo, per identificare un nuovo cliente per creare un'associazione e, in secondo luogo, per richiedere all'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 richiesto e così via. Inoltre, il flusso di autenticazione può essere utilizzato in modalità autonoma, non associato a un 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 nella UI di Google che la invia all'integratore. In questo modo viene attivata una risposta positiva da parte dell'integratore dei pagamenti.

Quando l'autenticazione OTP SMS-MT viene utilizzata in modalità autonoma, il valore dell'OTP viene inviato all'integratore utilizzando il metodo verifyOtp. Questo metodo permette di verificare che l'OTP fornito sia stato inviato.

Autenticazione reindirizzamento

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

Il comportamento di reindirizzamento di Android e di reindirizzamento web è simile. Google reindirizza l'utente all'app dell'integratore. L'integratore identifica e autentica l'utente nella forma più naturale per tale integratore. Una volta autenticato, l'integratore reindirizza l'utente all'UI 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à 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 (desktop o mobile). Tuttavia, l'autenticazione Android è vivamente consigliata per offrire la migliore esperienza utente sui dispositivi mobili.

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

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

Nota: se l'integratore utilizzerà l'OTP SMS-MT durante il reindirizzamento, Google consiglia vivamente di utilizzare l'autenticazione OTP SMS-MT sopra indicata. Offre 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 menzionati in precedenza, l'utente passa al flusso di associazione. Lo scopo della procedura di associazione è stabilire un token di Google Payment (GPT) per creare uno strumento. Questo flusso svolge le seguenti operazioni:

1. Negozia un'identità denominata token per rappresentare l'utente.
2. Fornisce informazioni sull'account per informare il motore dei rischi di Google.
3. Raccoglie le informazioni necessarie per la prima configurazione per creare e stabilire l'GPT.

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

È possibile che due utenti Google condividano lo stesso account utente con l'integratore. In questo caso, ogni utente avrà uno strumento diverso. Per ogni strumento esiste un flusso di associazione indipendente e, di conseguenza, un GPT univoco.

Questa illustrazione illustra una forma di pagamento tokenizzata falsa, chiamata InvisiCash. Questo dimostra i passaggi che un utente deve seguire per il flusso di autenticazione e il flusso di associazione.

Panoramica del flusso di associazione

1. Una utente Google con indirizzo email [e-mail] vuole aggiungere il suo account InvisiCash al Google Play Store in modo da 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 email [e-mail]. È possibile che utilizzi il suo indirizzo email Gmail per entrambi, se questo è l'accesso al suo account InvisiCash.

   Nota: esistono altri metodi di autenticazione. Questo è solo un esempio. Questa operazione può anche essere eseguita sul web anziché tramite un'app.

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

5. Il Google Play Store invia l'ID 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, un GPT (token di pagamento Google) e un ID associazione.

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

8. InvisiCash approva questa associazione. In seguito, i server di Google creano uno strumento che può essere utilizzato per acquisti futuri.