Google Pay: in-app and web

1) What is Google Pay online

Google Pay (GPay) - a layer of secure payment over card rails (Visa/Mastercard/etc.), where the PAN is replaced by a device/network token (DPAN/network token), and the transaction is signed with a one-time EMV cryptogram. Authentication - biometrics/screen lock + device binding.
For the merchant, this is essentially a card CNP payment with increased conversion and less fraud. Disputes/refands - according to card rules.

2) Channels and scenarios

2. 1 Web

Integration via Google Pay JS (PaymentDataRequest).
Works in modern browsers (the best UX is Chrome/Android).
Confirmation in the browser/through the associated device (phone/watch) with biometrics.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App confirmation in GPay app, status return to your app.

2. 3 POS (NFC)

CP scenario via HCE/SE; outside of the online article, the chargeback rules are different.

3) Tokenization and security

DPAN/Network Token is issued by the network token service; The PAN does not leave the device.
For each payment, an EMV cryptogram (one-time signature) is formed.
SCA is closed by biometrics/screen lock of the device (PSD2-compatible).
Payment Token is decrypted at the PSP/gateway (gateway-mode) or at the merchant with the appropriate certificates (direct-mode; rarely).

4) SCA/3DS model and risk

In EC/PSD2, SCA is often performed at the Google Pay level → a separate 3DS may not start (bank/PSP decides).
The issuer/network may request additional verification/rejection of the transaction (especially for high-risk MCC).
Selective failures and reduced limits are possible for sensitive verticals.

5) MIT/recurrence and COF

Google Pay token for one-off transaction is not eligible for re-debiting.

• The first payment through GPay → obtain consent for MIT → tokenize the card in COF (Network Token/VTS/MDES) from the PSP/acquirer.
• Further write-offs are like MIT with a COF token with the correct transaction markup.
• Without COF and bank consent - high decline/chargeback risks.

6) Connectivity options: gateway vs direct

Gateway (recommended): 'tokenizationSpecification. type = "PAYMENT_GATEWAY"' → PSP decrypts the token and performs authorization. Fast start, less compliance.
Direct: 'type = "DIRECT"' → merchant independently decrypts the card network token. Need certificates/keys and the strictest security; rarely applied.

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

7) Integration flows

7. 1 Web (steps)

1. GPay client initialization → isReadyToPay check.
2. Collection of PaymentDataRequest (with networks, authentication methods and tokenization).
3. Display GPay Sheet → user confirms (SCA).
4. Receive paymentMethodData (cipher token) and send to PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. 'Capture/refund' by need; recon - by daily registers.

7. 2 Android (in-app)

Similarly, create a'PaymentsClient ', pass a'PaymentDataRequest', get a token and pass it to the backend/PSP.

8) Statuses, settlements and returns

Online statuses: 'authorized/succeeded/failed/cancelled' (+ 'pending' in some PSPs).
Settlement: by PSP/acquirer registers, usually T + 1/T + 2. Separate online success and accounting enrollment.
Refund: partial/complete by card rules.
Chargeback: the card procedure (INR/NAD, etc.) remains relevant.

9) Frequent failure causes (declines)

MCC/vertical (iGaming/quasi-cache) - selective blocking for issuers/PSP.
Mismatch geo (map country/IP/merchant location).
Incorrect'PaymentDataRequest 'configuration (networks/authentication methods), incorrect' merchantId'or tokenization mode.
MIT without COF/consent.
SCA Timeouts/User Flow Interrupt.

10) UX patterns (which boosts conversion)

Mobile-first: bring out the Google Pay button first method on Android.
Large GPay button on the product card/basket/checkout; follow the brand guide.
Pre-fill amount/taxes/delivery to Sheet (user-visible total).
Recovery: safe repetition at timeouts, switching to cards/A2A at repeated failures.
Desktop↔mobayl: QR/hand-off if the user confirms on the phone.

11) Smart routing

Offer GPay on Android/Chrome and for BINs/banks with a high approve rate.
Auto-derating GPay on specific BIN/geo when indicators are degraded.
For recurrents: first payment via GPay → COF, then MIT without user intervention.

12) Safety and compliance

Validation of PSP message signatures/web hooks, strict 'redirect/return' URIs.
Keys/secrets - in vault, IP-allowlist for callback-endpoints.
PCI footprint is minimal in gateway-mode (you don't touch PAN/secrets).
Logs: device hints, reason codes, SCA/confirm time.

13) iGaming: Features

Availability and limits vary by jurisdiction, PSP and issuer.
Expect selective failures and/or reduced limits; check local rules.
Recurrent write-offs - only MIT with COF and documented player consents.
Keep alternatives: A2A/open-banking, local wallets, eCash. Enter fallback if the decline is high on GPay.

14) Reconciliation and reporting (recon)

• 'paymentId/transactionId ', 'orderId', network (Visa/MC/...), BIN/bank, amount/currency, status/refusal codes, channel (Web/In-App), timestamps, ARN/UTR from registries.

Daily auto-recon + periodic full-recon.

Alerts: "online success without a registry," "double capture," "aging auth."

15) KPI and method management

Approval rate GPay vs regular cards (by banks/BIN/geo/devices).
Share of GPay in Android traffic, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Auto-deriving threshold rules (for example, approve <X% for a specific BIN/geo).

16) Output checklist

1. Connect GPay at PSP; get merchantId, configure allowedPaymentMethods/networks and tokenizationSpecification.
2. Implement Web/In-App Sheet, 'authorize/capture/refund', webhooks (signature/NMAS), idempotency and retrays.
3. Configure COF/network tokenization for MIT + store consent.
4. Enable smart-routing: GPay priority on Android, fallback on cards/A2A.
5. Checking brand guides (buttons/icons/copyright).
6. Build recon and alerts: out of sync, aging auth, double capture.
7. E2E tests: Web/Android, partial capture/refund, timeouts/replays, PSP degradation, high loads.

Landmark card

Rail: card (Visa/MC/...); chargeback - according to the rules of cards.
SCA: biometrics/screen lock (PSD2-compatible); 3DS is usually not required separately.
Tokenization: DPAN + EMV cryptogram; for the recurrent - COF/network token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: by PSP registers (T + 1/T + 2).
Limitations: availability by device/browser/geo; for iGaming - PSP/issuer policy.

Resume Summary

Google Pay is a card payment accelerator with high mobile conversion and built-in SCA. Integrate via gateway-mode, meet PaymentDataRequest requirements, build around webhooks + idempotency + recon, and use COF for recurrents. For iGaming - keep alternative rails and smart routing as availability and limits vary by jurisdiction, bank and PSP.