Google Pay: in-app y web

1) Qué es Google Pay en línea

Google Pay (GPay) es una capa de pago seguro sobre los raíles de tarjetas (Visa/Mastercard/et al.), donde el PAN es reemplazado por un token de dispositivo/red (DPAN/red token) y la transacción se firma con un criptograma EMV de un solo uso. Autenticación - biometría/skrin-lock + device binding.
Para merchant, es esencialmente un pago CNP con tarjeta con mayor conversión y menos frodo. Disputs/Refundiciones - según las reglas de las tarjetas.

2) Canales y scripts

2. 1 Web

Integración a través de Google Pay JS (PaymentDataRequest).
Funciona en navegadores modernos (el mejor UX es Chrome/Android).
Confirmación en el navegador/a través de un dispositivo asociado (teléfono/reloj) con biometría.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App confirmación en la aplicación GPay, devuelve el estado a tu aplicación.

2. 3 POS (NFC)

script CP a través de HCE/SE; fuera del marco del artículo en línea, las reglas de charjback son diferentes.

3) Tokenización y seguridad

DPAN/Network Token es emitido por el servicio de token de la red; PAN no sale del dispositivo.
Para cada pago se genera un criptograma EMV (firma única).
El SCA se cierra con biometría/skrin-lock del dispositivo (PSD2-compatible).
Payment Token se descifra en PSP/gateway (modo gateway) o en el merchant si hay certificados adecuados (modo directo; rara vez).

4) Modelo de SCA/3DS y riesgo

El EC/PSD2 SCA a menudo se ejecuta en el nivel de Google Pay → es posible que no se ejecute un 3DS separado (decide el banco/PSP).
El emisor/red puede solicitar la verificación dop/rechazar la transacción (especialmente para MCC de alto riesgo).
Para verticales sensibles, los fallos selectivos y los límites reducidos son posibles.

5) MIT/recurrent y COF

El token de Google Pay para una transacción one-off no es adecuado para volver a cargar.

• El primer pago a través de GPay → obtener el consentimiento del MIT → tokenizar la tarjeta en el COF (Network Token/VTS/MDES) del PSP/ecuador.
• Otros cargos - como MIT con un token COF con la marca de transacción correcta.
• Sin el COF y el consentimiento del banco - altos riesgos decline/chargeback.

6) Opciones de conexión: gateway vs direct

Gateway (recomendado): 'tokenizationSpecification. type = "PAYMENT_GATEWAY"' → PSP descifra el token y realiza la autorización. Inicio rápido, menos cumplimiento.
Direct: 'type = «DIRECT»' → merchant decodifica el token de la red de tarjetas por sí mismo. Se necesitan certificados/claves y la más estricta seguridad; rara vez se aplica.

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

7) Flujos de integración

7. 1 Web (pasos)

1. Inicialización del cliente de GPay → verificación de isReadyToPay.
2. Recopilar PaymentDataRequest (con redes, métodos de autenticación y tokenización).
3. Muestra GPay Sheet → el usuario confirma (SCA).
4. Recibe paymentMethodData (cifrado) y lo envía a PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. 'capture/refund' por necesidad; recon - por registros diarios.

7. 2 Android (in-app)

Del mismo modo: crea 'PaymentsClient', pasa 'PaymentDataRequest', recibe el token y lo pasa al backend/PSP.

8) Estados, cálculos y devoluciones

Estados en línea: 'authorized/succeeded/failed/canceled' (+ 'pending' en algunos PSP).
Settlement: por registros PSP/ecuador, normalmente T + 1/T + 2. Comparta el éxito en línea y la inscripción contable.
Refund: parcial/completo según las reglas de la tarjeta.
Chargeback: el procedimiento de tarjeta (INR/NAD, etc.) sigue siendo relevante.

9) Causas frecuentes de fallos (declines)

MSS/vertical (iGaming/quasi caché) - bloqueos selectivos en emisores/PSP.
Mismatch geo (país del mapa/IP/ubicación del merchant).
Configuración incorrecta de 'PaymentDataRequest' (redes/métodos de autenticación), 'merchantId' incorrecto o modo de tokenización.
MIT sin COF/consent.
Tiempo de espera SCA/interrupción del flow personalizado.

10) Patrones UX (que aumenta la conversión)

Mobile-first: saca el botón de Google Pay con el primer método en Android.
Botón grande GPay en la tarjeta del artículo/carrito de compras/checkout; cumpla con la marca hyde.
Pre-fill importes/impuestos/envíos a Sheet (usuario-visible total).
Recuperación: repetición segura durante los tiempos de espera, cambiar a tarjetas/A2A en los fallos repetidos.
Desktop↔mobayl: QR/hand-off si el usuario confirma en el teléfono.

11) Enrutamiento inteligente

Ofrezca GPay con Android/Chrome y para BIN 's/bancos de alta velocidad.
Auto-deseriting GPay en BIN/geo específicos cuando los indicadores se degradan.
Para los reclutas: primer pago a través de GPay → COF, luego MIT sin participación del usuario.

12) Seguridad y cumplimiento

Validación de firmas de mensajes/ganchos web PSP, estrictos URI 'redesp/return'.
Claves/secretos - en vault, IP-allowlist para los endpoints de callback.
La huella PCI es mínima en el modo gateway (no tocas PAN/secretos).
Logs: device hints, reason codes, tiempo SCA/conferm.

13) iGaming: características

La disponibilidad y los límites dependen de la jurisdicción, el PSP y el emisor.
Espere fallos selectivos y/o límites reducidos; compruebe las reglas locales.
Las deducciones recurribles son sólo del MIT con COF y los acuerdos documentados del jugador.
Mantenga las alternativas: A2A/open-banking, billeteras locales, eCash. Escriba fallback con alta definición en GPay.

14) Conciliación y presentación de informes (recon)

• 'paymentId/transactionId', 'orderId', red (Visa/MC/...), BIN/banco, suma/moneda, estado/códigos de denegación, canal (Web/In-App), timestamps, ARN/UTR de los registros.

Daily auto-recon + periódico full-recon.
Alertas: «éxito online sin registro», «doble captura», «aging auth».

15) KPI y gestión del método

Approval rate GPay vs tarjetas normales (por bancos/BIN/geo/dispositivos).
Compartir de GPay en el tráfico Android, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Reglas de umbral de auto-eliminación (por ejemplo, approve <X% en un BIN/geo específico).

16) Check-list de la salida en el prod

1. Conecte GPay en PSP; obtenga merchantId, configure allowedPaymentMethods/networks y tokenizationSpecification.
2. Implementar Web/In-App Sheet, 'authorize/capture/refund', webhooks (firma/NMAS), idempotencia y retrés.
3. Configurar la tokenización COF/red para MIT + almacenar consent.
4. Habilita smart-routing: prioridad GPay en Android, fallback en tarjetas/A2A.
5. Comprobación de marcas (botones/iconos/copyright).
6. Construye recon y alertas: rassincrones, aging auth, doble capture.
7. Pruebas E2E: Web/Android, capture/refund parcial, temporizadores/repeticiones, degradación PSP, altas cargas.

Tarjeta de referencia

Carril: tarjeta (Visa/MC/...); chargeback - según las reglas de las tarjetas.
SCA: biometría/skrin-lock (PSD2-compatible); Por lo general, no se requiere 3DS por separado.
Tokenización: DPAN + criptograma EMV; para el recurso - COF/red token.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Settlement: por registros PSP (T + 1/T + 2).
Restricciones: disponibilidad por dispositivo/navegador/geo; para iGaming: política PSP/emisores.

Resumen

Google Pay es un «acelerador» de pagos con tarjeta con alta conversión móvil y SCA incorporada. Integre a través del modo gateway, cumpla con los requisitos de PaymentDataRequest, construya alrededor de webhooks + idempotencia + recon y utilice COF para los reclutas. Para iGaming: mantenga los raíles alternativos y el enrutamiento inteligente, ya que la disponibilidad y los límites dependen de la jurisdicción, el banco y el PSP.