Nel mondo dei pagamenti standard di Google, la fatturazione con l'operatore è considerata una forma di pagamento tokenizzata, il che significa che Google e l'integratore dei pagamenti eseguono uno scambio una tantum delle credenziali di identità dell'account per stabilire un token. In seguito, il token viene presentato all'integratore dei pagamenti per identificare l'account da addebitare.
Anche altre forme di pagamento utilizzano la tokenizzazione, pertanto abbiamo una panoramica generale delle forme di pagamento tokenizzate, che è per lo più pertinente alla Fatturazione con l'operatore. I flussi di autenticazione, associazione, acquisto e rimessa sono descritti in maggiore dettaglio in questa panoramica. Questa pagina fornisce ulteriori dettagli in un contesto specifico della Fatturazione con l'operatore.
Gli operatori effettuano l'onboarding per i pagamenti standard di Google implementando le API che compongono i seguenti flussi:
| Flusso | Descrizione | Equivalente specifica DCB3 |
|---|---|---|
| Autenticazione | Identifica e autentica l'account dell'utente nel sistema dell'integratore pagamenti che verrà utilizzato per effettuare pagamenti tramite fatturazione diretta con l'operatore | SMS-MO con GoogleUserToken |
| Associazione | Scambia un token di lunga durata concordato da Google e dall'integratore dei pagamenti che può essere utilizzato per effettuare pagamenti utilizzando l'account dell'integratore dei pagamenti dell'utente | approva callback utente con OperatorUserToken e GetProvisioning() |
| FundsTransfer | Trasferisce in modo sincrono i fondi dall'account dell'integratore dei pagamenti dell'utente. Trasferisce la responsabilità all'integratore dei pagamenti | Righe Auth() e CHARGE nei file di richiesta batch |
| Rimborso | Restituisce in modo sincrono alcuni o tutti i fondi associati a un precedente Trasferimento di fondi nell'account di integrazione dei pagamenti dell'utente. Trasferisce la responsabilità a Google | RIMBORSA le righe nei file di richiesta batch |
| Versamento | Liquidazione basata su API, preferibilmente su base giornaliera | PDF della fattura mensile, file dei dettagli della fattura mensile, file di riconciliazione giornaliera |
| UpdateAssociatedAccount | Informa Google delle modifiche apportate all'account dell'integratore pagamenti di un utente (ad esempio, limiti alle transazioni o stato del provisioning) | Sondaggio GetProvisioning() |
| Attività fraudolenta | Informa Google delle transazioni annullate a causa di una contestazione dell'utente. Viene utilizzato per migliorare il motore dei rischi di Google, ma non incide sulla responsabilità monetaria | Nessuno |
Confronto complessivo con le specifiche DCB3
La specifica di Google Standard Payments risolve gli stessi problemi della specifica DCB3. Tuttavia, utilizza tecnologie e progettazioni di API diverse che migliorano la soluzione. Ecco le principali differenze:
Confronto tra tecnologie stack
Tutte le comunicazioni con le API vengono effettuate utilizzando POST HTTPS con JSON firmato e criptato con PGP. Ciò significa che Google e l'integratore dei pagamenti hanno una sola chiave PGP da ruotare. Queste tecnologie hanno anche un supporto migliore rispetto a SOAP. Ulteriori dettagli sullo stack di comunicazione sono disponibili qui.
Confronto tra la filosofia delle API
La fatturazione diretta con l'operatore fa molto affidamento sui file per riconciliare lo stato dei pagamenti. Google Standard Payments non ha file. Le chiamate API vengono tentate di nuovo in modo idempotente e a tempo indeterminato finché non viene determinato uno stato finale.
Gli stati finali sono realmente definitivi per una determinata chiave di idempotenza. I bug e gli stati indeterminati non sono modellati come rifiuti, ma come risposte HTTP non 200. Questo ci consente di individuare più rapidamente i bug e di evitare di mascherarli come rifiuti.
Nuove funzionalità
Google Standard Payments supporta nuove funzionalità, tra cui:
- l'API Fraud per informare il motore di Google dei rischi
- Aggiorna l'API Associated Account per informare Google in merito a provisioning, limiti delle transazioni e modifiche allo stato degli account
- Maggiore supporto per la verifica dell'autenticazione durante gli acquisti, ad esempio i PIN USSD
- Ciclo di rimessa giornaliero
Mappa della terminologia dei pagamenti standard per i pagamenti dalla DCB3 a Google
In questa documentazione e nella specifica stessa, troverai una terminologia che sembra nuova, ma che in realtà è composta da parole diverse per concetti esistenti.
- Operatore -> Integratore pagamenti
AVVISO: per evitare confusione con il concetto di integratore DCB, questo documento tenta di utilizzare "Integratore pagamenti" e "Integratore DCB" anziché semplicemente "integratore". Tuttavia, la documentazione generale di Google Standard Payments utilizza liberamente "integratore" come forma abbreviata di "Integratore pagamenti"
- ID contratto di fatturazione -> ID account integratore pagamenti
- OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
- correlazione_id -> ID richiesta
- Quota di condivisione delle entrate -> tariffa
Flusso di autenticazione
Per una panoramica generale del flusso di autenticazione per le FOP tokenizzate, consulta questa pagina.
Specifiche di fatturazione con l'operatore
Per la Fatturazione con l'operatore, l'obiettivo del flusso di autenticazione è dimostrare che l'utente ha il controllo della scheda SIM associata all'account del suo operatore. Gli utenti con fatturazione con l'operatore possono essere autenticati utilizzando uno di questi tre meccanismi:
- Autenticazione SMS-MO (Definizione nella panoramica della forma di pagamento tokenizzata)
- Autenticazione di reindirizzamento (Definizione nella panoramica della forma di pagamento tokenizzata)
- OTP SMS-MT (Definizione in FOP tokenizzata)
Gli integratori dei pagamenti possono collaborare con Google per scegliere i meccanismi di autenticazione più adatti al proprio prodotto.
Confronto con la fatturazione diretta con l'operatore 3
Il flusso di autenticazione sostituisce il callback approveuser per Google con la specifica DCB3.
In DCB3, autenticazione e associazione sono state combinate in un unico flusso. In Google Standard Payments, l'autenticazione è un problema diverso dall'associazione degli account.
Flusso di associazione
Per una panoramica generale del flusso di associazione per le forme di pagamento tokenizzate, visita questa pagina.
La differenza principale tra il flusso di associazione utilizzato per gli strumenti di fatturazione con l'operatore e il flusso generale delle FOP tokenizzate è che la prova di autenticazione fornita nel metodo associateAccount varia a seconda che l'integratore dei pagamenti richieda o meno una verifica aggiuntiva dell'utente.
Se l'integratore dei pagamenti ha risposto all'intenzione di un'ulteriore verifica dell'utente, la prova dell'autenticazione sarà qualsiasi prova di identità prodotta dal particolare meccanismo di autenticazione utilizzato da Google per la verifica aggiuntiva. Ad esempio, la prova di autenticazione prodotta dal meccanismo OTP SMS-MT è l'ID richiesta di un metodo sendOtp più l'OTP stesso.
Attributi dello strumento
La sezione Attributi dello strumento della panoramica generale della forma di pagamento tokenizzata illustra il concetto di accountAlias, accountNickname e fullAccountNickname.
Specifiche di fatturazione con l'operatore
accountAliasdeve essere il numero di telefono dell'utente. Verrà utilizzata per identificare lo strumento nel caso in cui l'utente chiami l'Assistenza Google in merito al proprio account.accountNicknameefullAccountNicknamesono nomi visualizzati utilizzati per identificare lo strumento nella UI.
Confronto con le specifiche DCB3
Il flusso di associazione sostituisce i seguenti componenti della specifica DCB3:
- Chiamata SOAP GetProvisioning
- Chiamata SOAP Get SubscriberAddress
- OUT generato dall'operatore
Una grande differenza qui è il fatto che Google genera il token di Google Payments (GPT) durante il flusso dell'associazione, invece che l'operatore che lo genera.
È inoltre importante notare che, a differenza di DCB3, in cui gli OUT hanno come ambito un determinato Billing AgreementId, GPT non ha come ambito un particolare PaymentIntegratorAccountID.
Aggiorna flusso di token
Per una panoramica generale del flusso del token di aggiornamento per le FOP tokenizzate, visita questa pagina.
Specifiche di fatturazione con l'operatore
Per gli strumenti di Fatturazione con l'Operatore, sconsigliamo vivamente la scadenza dei Token di pagamento di Google, in quanto comportano l'annullamento degli ordini di abbonamento. Anziché far scadere i token e fare affidamento sul flusso dei token di aggiornamento per correggerli, il caso d'uso spesso può essere realizzato utilizzando il flusso di aggiornamento dell'account descritto di seguito.
Flusso di aggiornamento dell'account
Il flusso di aggiornamento dell'account consente all'integratore dei pagamenti di informare Google sugli aggiornamenti all'account di integrazione dell'utente. Questi campi sono originariamente forniti a Google durante il flusso dell'associazione. Ecco alcuni esempi di dati dell'account che l'integratore dei pagamenti potrebbe voler aggiornare:
- i limiti di transazione mensili, giornalieri e per articolo dell'utente
- lo stato di provisioning dell'account di integrazione dell'utente
- Il tipo di account dell'integratore dell'utente (prepagato, post-pagato, aziendale e così via)
- l'"accountAlias", "accountNickname" o "fullAccountNickname"
- se l'utente ha impostato, rimosso o modificato un PIN statico precondiviso
- Indica se l'utente ha chiuso l'account o modificato il numero di telefono, annullando la validità dello strumento dell'utente nel sistema Google.
- elimina flusso di token
Confronto con le specifiche DCB3
Il flusso di aggiornamento dell'account sostituisce i seguenti componenti della specifica DCB3:
- Polling della chiamata SOAP GetProvisioning
- Annullamento periodico del token
Flusso di acquisto
Per una panoramica generale del flusso di acquisto per le forme di pagamento tokenizzate, visita questa pagina.
Specifiche di fatturazione con l'operatore
Alcuni operatori utilizzano USSD o un'altra tecnologia per raccogliere un PIN dagli utenti durante ogni acquisto. Per questi operatori, anziché chiamare la funzione Capture(), chiamiamo adirectional Capture() e concediamo all'operatore 30 secondi per richiedere il PIN all'utente e finalizzare l'acquisizione. Una volta determinato lo stato finale del pagamento, l'operatore informa Google del risultato chiamando captureResultNotification().
Confronto con le specifiche DCB3
Ci sono cambiamenti importanti qui.
- Chiamata singola e sincrona al metodo: Capture() anziché auth() + file batch
- Nessun file batch
- Nessun metodo cancel() (acquisizione + rimborso invece di autorizzazione + annulla)
- Nessun campo user_message nella risposta: i codici di rifiuto sono mappati ai messaggi di proprietà di Google localizzati nella lingua dell'account dell'utente.
- Modifiche terminologiche principali:
- ID correlazione -> ID richiesta
- BillingAgreementId -> paymentIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
Flusso di acquisto contestato
È in corso lo sviluppo per supportare un flusso di acquisto che includa una verifica di autenticazione per l'utente prima di ogni acquisto. La maggior parte dei metodi di autenticazione che possono essere utilizzati prima del flusso di associazione può essere utilizzata anche prima del flusso di acquisto contestato per fornire un'autenticazione utente aggiuntiva.
Flusso di rimborso
Per una panoramica generale del flusso di rimborso per le forme di pagamento tokenizzate, visita questa pagina.
La forma di pagamento tokenizzata supporta un flusso di rimborso singolo. Il metodo di rimborso consente il rimborso di un acquisto totale o di una parte dell'acquisto. Più rimborsi parziali possono richiedere il rimborso di un singolo acquisto.
Specifiche di fatturazione con l'operatore
Non c'è niente di speciale sugli strumenti di Fatturazione con l'operatore nel flusso di rimborso.
Confronto con le specifiche DCB3
I rimborsi vengono attivati da una chiamata API sincrona anziché da un file. Inoltre, è possibile creare più rimborsi parziali per un singolo pagamento originale, anziché supportare un solo rimborso completo del valore.
Flusso di versamento
Per una panoramica generale del flusso di pagamento per le FOP tokenizzate, consulta questa pagina.
Il flusso di pagamento è il modo in cui Google e l'integratore dei pagamenti eseguono la transazione. Google è il sistema di contabilità e si occupa dei trasferimenti dei pagamenti. Con regolarità, Google invia una distinta di accompagnamento all'integratore dei pagamenti. L'estratto conto fornisce un riepilogo dell'importo che l'integratore dei pagamenti deve a Google, insieme alle istruzioni su come pagare a Google. Per consentire all'integratore dei pagamenti di eseguire la riconciliazione, quest'ultimo può eseguire una query su Google per i dettagli a livello di transazione che costituiscono l'estratto conto.
Specifiche di fatturazione con l'operatore
Fatturazione con l'operatore remittanceStatementDetails include campi aggiuntivi non ancora elencati nelle definizioni API del flusso di pagamento. Queste includono:
- revshareCategory
- itemPrice
- tax
- timestamp
Per gli operatori con un contratto di ripartizione delle entrate pari a 50/50 con Google, le tariffe indicate in remittanceStatementDetails vengono aggregate per revshareCategory invece di essere presentate per evento.
Confronto con le specifiche DCB3
Il flusso di pagamento sostituisce i seguenti concetti nella specifica DCB3:
- PDF Report sull'addebito mensile/Report sui pagamenti
- File CSV con i dettagli della fattura mensile
- File CSV di ricognizione giornaliera
Le principali differenze sono la rimozione di tutti i file e l'assistenza per le rimesse giornaliere. Invece dei file, l'importo da versare viene fornito tramite un'API sincrona e un'altra API supporta l'esecuzione di query per i dettagli sulla dichiarazione di versamento.
Flusso dei report sulle frodi
Il flusso di segnalazione di attività fraudolente consente a un integratore dei pagamenti di informare Google di transazioni potenzialmente fraudolente richiamando il metodo fraudNotification. Questo flusso viene utilizzato per aggiornare il motore di gestione dei rischi interno di Google e non avvia alcun trasferimento di denaro.
Specifiche di fatturazione con l'operatore
Non c'è niente di speciale sugli strumenti di Fatturazione con l'operatore nel flusso di notifica dell'annullamento dei pagamenti.