Google Pay : in-app et web

1) Qu'est-ce que Google Pay en ligne

Google Pay (GPay) est une couche de paiement sécurisé sur les rails de carte (Visa/Mastercard/etc.), où le PAN est remplacé par un jeton d'appareil/réseau (DPAN/network token) et la transaction est signée par un cryptogramme EMV unique. L'authentification est biométrique/screen-lock + device binding.
Pour le merchant, c'est essentiellement un paiement CNP par carte avec une conversion accrue et moins de frod. Disputes/refandes - selon les règles de la carte.

2) Canaux et scripts

2. 1 Web

Intégration via Google Pay JS (PaymentDataRequest).
Fonctionne dans les navigateurs modernes (le meilleur UX - Chrome/Android).
Confirmation dans le navigateur/via l'appareil associé (téléphone/horloge) avec biométrie.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App une confirmation dans l'application GPay, un retour de statut à votre application.

2. 3 POS (NFC)

CP-script via HCE/SE ; en dehors de l'article en ligne, les règles des chargbacks sont différentes.

3) Tokenization et sécurité

DPAN/Network Token est délivré par le service de réseau ; Le PAN ne quitte pas l'appareil.
Un cryptogramme EMV (signature unique) est généré pour chaque paiement.
SCA est fermé par biométrie/scryn-lock de l'appareil (compatible PSD2).
Payment Token est déchiffré à la PSP/passerelle (gateway-mode) ou au merchant si vous avez les certificats appropriés (direct-mode ; rarement).

4) Modèle de SCA/3DS et risque

Dans le EC/PSD2 SCA est souvent exécuté au niveau de Google Pay → une 3DS distincte peut ne pas démarrer (décide de la banque/PSP).
L'émetteur/le réseau peut demander une vérification dop/refuser la transaction (en particulier pour les MCC à risque élevé).
Pour les verticaux sensibles, des pannes sélectives et des limites réduites sont possibles.

5) MIT/recurrent et COF

Le token Google Pay pour une transaction one-off n'est pas apte à être débité à nouveau.

• Le premier paiement via GPay → obtenir l'accord du MIT → tokeniser la carte dans le COF (Network Token/VTS/MDES) auprès du PSP/acquéreur.
• D'autres débits - comme le MIT avec le token COF avec le marquage correct de la transaction.
• Sans le COF et l'accord de la banque - des risques élevés decline/chargeback.

6) Options de connexion : gateway vs direct

Gateway (recommandé) : 'tokenizationSpecification. type = "PAYMENT_GATEWAY"' → PSP déchiffre le jeton et effectue l'autorisation. Démarrage rapide, moins de complication.
Direct : 'type = « DIRECT »' → le merchant déchiffre lui-même le jeton du réseau de cartes. Vous avez besoin de certificats/clés et d'une sécurité plus stricte ; rarement appliqué.

• `allowedPaymentMethods` → `type: "CARD"`, `parameters. allowedAuthMethods` (`PAN_ONLY`, `CRYPTOGRAM_3DS`), `allowedCardNetworks`, `billingAddressParameters`.
• `tokenizationSpecification` → `gateway` или `direct`.
• 'TransactionInfo '→ le montant/devise/totalPriceStatus.
• `merchantInfo` → `merchantId`/`merchantName`.

7) Flux d'intégration

7. 1 Web (étapes)

1. Initialiser le client GPay → vérifier isReadyToPay.
2. Collecte de PaymentDataRequest (avec réseaux, méthodes d'authentification et tokenisation).
3. Afficher GPay Sheet → l'utilisateur confirme (SCA).
4. Recevoir paymentMethodData (chiffrement) et l'envoyer à PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. "capture/refund'par besoin ; recon - selon les registres quotidiens.

7. 2 Android (in-app)

De même : vous créez 'PaymentsClient', vous passez 'PaymentDataRequest', vous recevez un jeton et vous le transférez au backend/PSP.

8) Statuts, calculs et retours

Statuts en ligne : 'autorisé/succeeded/failed/canceled' (+ 'pending'chez certains PSP).
Settlement : selon les registres PSP/acquéreur, généralement T + 1/T + 2. Partagez le succès en ligne et l'inscription comptable.
Refund : partiel/complet selon les règles de la carte.
Chargeback : la procédure de cartes (INR/NAD, etc.) reste d'actualité.

9) Causes fréquentes de refus (declines)

MSS/vertical (iGaming/quasi-cache) - verrouillage sélectif des émetteurs/PSP.
Mismatch geo (pays carte/IP/localisation du merchant).
Configuration incorrecte 'PaymentDataRequest' (réseaux/méthodes d'authentification), 'merchantId' incorrect ou mode de tokenization.
MIT sans COF/consent.
Temporisation SCA/interruption de flow utilisateur.

10) modèles UX (ce qui augmente la conversion)

Mobile-first : sortez le bouton Google Pay avec la première méthode sur Android.
Un gros bouton GPay sur la carte produit/panier/checkout ; respectez l'hyde de marque.
Pre-fill montants/taxes/livraison dans Sheet (user-visible total).
Récupération : répétition sécurisée en cas de temporisation, basculement vers les cartes/A2A en cas de pannes répétées.
Desktop↔mobayl : QR/hand-off si l'utilisateur confirme sur le téléphone.

11) Routage intelligent

Offrez GPay sous Android/Chrome et pour les banques BIN's/avec un vol d'approche élevé.
Auto-deryting GPay sur des BIN/geo spécifiques lors de la dégradation des indicateurs.
Pour les récurrents : premier paiement via GPay → COF, puis MIT sans participation de l'utilisateur.

12) Sécurité et conformité

Validation des signatures de message/Web hooks PSP, stricte 'redirect/return'URI.
Les clés/secrets sont dans vault, IP-allowlist pour callback-endpoints.
La trace PCI est minimale dans le mode gateway (vous ne touchez pas au PAN/secrets).
Logs : device hints, codes reason, temps SCA/confirm.

13) iGaming : caractéristiques

La disponibilité et les limites dépendent de la juridiction, du PSP et de l'émetteur.
Attendre des échecs sélectifs et/ou des limites réduites ; vérifiez les règles locales.
Les débits récurrents ne sont que le MIT avec le COF et les consentements documentés du joueur.
Gardez des alternatives : A2A/open-banking, portefeuilles locaux, eCash. Tapez fallback lorsque la décline est élevée sur GPay.

14) Rapprochement et rapports (recon)

• 'paymentId/transactionId ',' orderId ', network (Visa/MC/...), BIN/banque, montant/monnaie, statut/codes de refus, canal (Web/In-App), timestamps, ARN/UTR des registres.

Daily auto-recon + périodique full-recon.
Alert : « succès en ligne sans registre », « double capture », « aging auth ».

15) KPI et gestion de la méthode

Approval rate GPay vs cartes ordinaires (par banques/BIN/géo/appareils).
Partager de GPay dans le trafic Android, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Règles de seuil auto-deryting (par exemple, approve <X % pour un BIN/geo particulier).

16) Chèque-liste de sortie dans la prod

1. Connecter le GPay au PSP ; obtenez merchantId, configurez allowedPaymentMethods/networks et tokenizationSpecification.
2. Implémentez Web/In-App Sheet, 'authorize/capture/refund', webhooks (signature/NMAS), idempotence et retraits.
3. Configurez la tokenization COF/réseau pour le MIT + stocker le consent.
4. Activer le routage intelligent : priorité GPay sur Android, fallback sur les cartes/A2A.
5. Vérification des hydes de marque (boutons/icônes/copirate).
6. Construisez recon et alerts : dissynchrones, aging auth, double capture.
7. E2E tests : Web/Android, capture partielle/refund, temporisation/répétitions, dégradation PSP, charges élevées.

Carte de repères

Rail : carte (Visa/MC/...) ; chargeback - selon les règles des cartes.
SCA : biométrie/screen-lock (compatible PSD2) ; 3DS n'est généralement pas nécessaire séparément.
Tokénisation : DPAN + cryptogramme EMV ; pour le recurrent - COF/network token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement : par registre PSP (T + 1/T + 2).
Restrictions : disponibilité par appareil/navigateur/géo ; pour iGaming - la politique PSP/émetteurs.

Résumé

Google Pay est un « accélérateur » de paiements par carte avec conversion mobile élevée et SCA intégré. Intégrez via le mode gateway, respectez les exigences de PaymentDataRequest, construisez autour de webhooks + idempotence + recon et utilisez le COF pour les répétitions. Pour iGaming - Gardez les rails alternatifs et le routage intelligent, car la disponibilité et les limites dépendent de la juridiction, de la banque et du PSP.