Google Pay: in-app e web

1) Cos'è Google Pay online

Google Pay è uno strato di pagamento sicuro sopra i binari di carte (Visa/Mastercard/ecc), dove PAN viene sostituito con il token del dispositivo/rete (DPAN/network token) e la transazione è sottoscritta da un crittogramma EMV monouso. Autenticazione: biometria/screen-lock + device bining.
Per il Merchant si tratta essenzialmente di un pagamento di carte CNP con maggiore conversione e meno frodo. Display/refanda, secondo le regole delle carte.

2) Canali e script

2. 1 Web

Integrazione con Google Pay JS (PaymentDataRequest).
Funziona in browser moderni (migliore UX - Chrome/Android).
Conferma nel browser/tramite dispositivo collegato (telefono/orologio) con biometria.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App Conferma in un'applicazione per la restituzione dello stato all'applicazione.

2. 3 POS (NFC)

Script CC tramite HCE/SE; fuori dall'articolo online, le regole dei charjbeek sono diverse.

3) Tokenizzazione e sicurezza

DPAN/Network Token viene fornito dal servizio di token della rete; PAN non lascia il dispositivo.
Per ogni pagamento viene generato un crittogramma EMV (firma monouso).
SCA viene chiuso con la biometria/screen-lock del dispositivo (PSD2-compatibile).
Payment Token è decodificato da PSP/gateway (gateway-mode) o da merchant se sono disponibili i certificati appropriati (direct-mode; raramente).

4) Modello SCA/3DS e rischio

In CE/PSD2 SCA è spesso eseguito a livello di Google Pay, un 3DS separato può non essere avviato (decide la banca/PSP).
L'emittente/rete può richiedere un controllo dop/rifiutare la transazione (in particolare per l'high-risk MCC).
Per le verticali sensibili sono disponibili guasti selettivi e limiti ridotti.

5) MIT/recurrent e COF

Il token Google Pay per la transazione one-off non è utilizzabile per il nuovo prelievo.

• Il primo pagamento tramite GPay consente di ottenere il consenso al MIT per il torning della carta in COF (Network Token/VTS/MDES) da PSP/Equier.
• Ulteriori prelievi sono come il MIT con il token COF con la marcatura della transazione corretta.
• Senza COF e il consenso della banca - alti rischi decline/conformeback.

6) Opzioni di connessione: gateway vs direct

Gateway (raccomandato): 'tokenizationSpecification. type = «PAYMENT _ GATEWAY» → PSP decodifica il token ed esegue l'autorizzazione. Partenza veloce, meno compliance.
Direct: 'type = «DIRECT», il merchant decodifica da solo il token della rete di carte. Servono certificati/chiavi e massima sicurezza; si applica raramente.

• `allowedPaymentMethods` → `type: "CARD"`, `parameters. allowedAuthMethods` (`PAN_ONLY`, `CRYPTOGRAM_3DS`), `allowedCardNetworks`, `billingAddressParameters`.
• `tokenizationSpecification` → `gateway` или `direct`.
• «transactionInfo» è la somma/valuta/ → PravaStatus.
• `merchantInfo` → `merchantId`/`merchantName`.

7) Flussi di integrazione

7. 1 Web (passi)

1. L'inizializzazione di un client → ay consente di verificare la isReadyToPay.
2. Raccolta di PaymentDataRequest (con reti, metodi di autenticazione e tornitura).
3. L'utente conferma (SCA) la visualizzazione di → ay Sheet.
4. Ricezione del paymentMethodData (cifrotocene) e invio al PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. 'capture/refund', per necessità; recon - sui registri giornalieri.

7. 2 Android (in-app)

Allo stesso modo, crea «PaymentsClient», passa «PaymentDataRequest», ottiene il token e lo trasmette al backend/PSP.

8) Stati, calcoli e restituzioni

States online: 'authorized/succeeded/failed/canceled' (+ 'pending'in PSP).
Settement: in base ai registri PSP/Equayer, di solito T + 1/T + 2. Condividi il successo online e l'iscrizione contabile.
Rifund: parziale/completo secondo le regole delle carte.
La procedura di mappatura (INR/NAD, ecc.) rimane valida.

9) Frequenti cause di guasti (decolli)

MSS/verticale (iGaming/quasi cache) - Blocchi selettivi in emittenti/PSP.
Mismatch geo (paese della mappa/IP/posizione del Merchant).
Configurazione «PaymentDataRequest» (reti/metodi di autenticazione) non valida, «merchantId» non valida o modalità di tornitura.
MIT senza COF/consent.
Timeout SCA/interruzione del flow utente.

10) Pattern UX (migliorando la conversione)

Mobile-first: porta il pulsante Google Pay con il primo metodo su Android.
Il pulsante più grande di GPay sulla scheda di prodotto/carrello/checkout; Rispettate il marchio hyde.
Pre-fill importo/tasse/consegne a Sheet (user-visual total).
Recovery: ripetizione sicura in caso di timeout, cambio a carte/A2A in caso di guasti ripetuti.
Desktop↔mobayl QR/hand-off se l'utente conferma sul telefono.

11) Routing avanzato

Offri una GPay con Android/Chrome e per BIN/banche ad alto tasso approve.
L'auto-dereiting di GPay su specifici BIN/geo per il degrado delle prestazioni.
Per i recurrent: il primo pagamento tramite GPay, COF, seguito da MIT, senza la partecipazione dell'utente.

12) Sicurezza e compliance

Convalida le firme dei messaggi/hook web PSP, rigide'redict/return'URI.
Chiavi/segreti - in vault, IP-allowlist per callback-endpoint.
La traccia PCI è minima in gateway-mode (non si tocca PAN/segreti).
Logi: device hints, reason codes, ora SCA/confirm.

13) iGaming: caratteristiche

La disponibilità e i limiti dipendono dalla giurisdizione, dal PSP e dall'emittente.
Attendere guasti selettivi e/o limiti ridotti; Controlla le regole locali.
I prelievi sono solo MIT con COF e consenso documentato del giocatore.
Mantieni le alternative: A2A/open-banking, portafogli locali, eCash. Digitare fallback quando la decline è alta su GPay.

14) Accoppiamento e reporting (recon)

• «paymentId/transactionId», «orderId», network (Visa/MC/...), BIN/banca, somma/valuta, stato/codici di rifiuto, canale (Web/In-App), timestamps, ARN/UTR dei registri.

Daily auto-recon + full-recon periodico.
«successo online senza registro», «doppia capture», «aging auth».

15) KPI e gestione del metodo

Approval rate GAE ay vs carte convenzionali (per banche/BIN/geo/dispositivi).
Share of FILEay nel traffico Android, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Regole di soglia per il dereiting automatico (ad esempio, approve <X% per un particolare BIN/geo).

16) Assegno foglio di output

1. Collegare il sistema di rete PSP; Ottieni un merchantId, allowedPaymentMethods/networks i e tokenizationSpecification.
2. Implementare Web/In-App Sheet, 'authorize/capture/refund', webhooks (firma/NMAS), idemotia e retrai.
3. Configurare COF/network tokenization per MIT + memorizzare il consent.
4. Abilita lo smart-routing come priorità per i file Android, fallback per le mappe/A2A.
5. Verifica delle etichette (pulsanti/icone/copiature).
6. Costruisci recon e alert: rassincroni, aging auth, doppi capture.
7. Test E2E: Web/Android, partial capture/refund, timeout/ripetizioni, degrado PSP, elevati carichi di lavoro.

Scheda di riferimento

Binario: a carte (Visa/MC/...); chargeback, secondo le regole delle carte.
SCA: biometria/screen-lock (PSD2-compatibile) 3DS di solito non è necessario separatamente.
Torning: crittogramma DPAN + EMV per il recurrent - COF/network token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settement: in base ai registri PSP (T + 1/T + 2).
Limitazioni: disponibilità per dispositivi/browser/geo; per i iGaming è un criterio PSP/emettitori.

Curriculum

Google Pay è un'acceleratore "dei pagamenti di carte con connessioni mobili elevate e SCA integrato. Integrare attraverso gateway-mode, rispettare i requisiti di PaymentDataRequest, costruire intorno a webhooks + idempotenza + recon e utilizzare il COF per i recurrent. Per i iGaming: mantenere binari alternativi e routing smart, poiché la disponibilità e i limiti dipendono dalla giurisdizione, dalla banca e dal PSP.