Google Pay: in-app e web

1) O que é o Google Pay online

Google Pay é uma camada de pagamento seguro sobre trilhos de cartas (Visa/Mastercard/etc), onde o PAN é substituído por um dispositivo/rede (DPAN/network tocen) e a transação é assinada por um criptograma EMV descartável. Autenticação - biometria/screen-lock + device binding.
Para o Merchant, é basicamente um pagamento CNP de cartão com maior conversão e menor frod. Displays/refanda - de acordo com as regras de cartas.

2) Canais e cenários

2. 1 Web

Integração através do Google Pay JS (PaymentDataRequest).
Funciona em navegadores modernos (o melhor UX é Chrome/Android).
Confirmação no navegador/através do dispositivo vinculado (telefone/relógio) com biometria.

2. 2 In-App (Android)

Google Pay API for Android (native sheet).
Deep Link/App2App confirmação no aplicativo SE, retornando o status para o seu aplicativo.

2. 3 POS (NFC)

Cenário COP por HCE/SE; fora do artigo online, as regras dos charjbacks são diferentes.

3) Toquenização e segurança

O DPAN/Network Token é emitido pelo serviço de token da rede; O PAN não sai do dispositivo.
Cada pagamento é formado por um criptograma EMV (assinatura descartável).
O SCA é fechado com biometria/screen-lock do dispositivo (PSD2-compatível).
O Payment Tokyo é decodificado em PSP/gateway-modo ou em merchant, se tiver os certificados apropriados (direto-modo; raramente).

4) Modelo SCA/3DS e risco

Em EC/PSD2 SCA é muitas vezes executado no nível Google Pay → um 3DS separado pode não ser executado (decide o banco/PSP).
O emissor/rede pode solicitar a verificação de Dops/rejeitar a transação (especialmente para high-risk MCC).
Para verticais sensíveis, pode haver falhas seletivas e limites reduzidos.

5) MIT/recurrent e COF

O Token Google Pay para transação one-off não é adequado para novo débito.

• O primeiro pagamento por meio do ay obter o seu consentimento para o MIT tornear o cartão para o COF (Rede Tocen/VTS/MDES) do PSP/Equador.
• Outros débitos são como o MIT com o token COF com sinalização correta da transação.
• Sem o COF e o consentimento do banco - altos riscos decline/chargeback.

6) Opções de conexão: gateway vs direto

Gateway (recomendado): 'tokenizationSpecification. tipo = «PAYMENT _ GATEWAY» '→ PSP decifra o token e autoriza. Início rápido, menos complacência.
Direto: 'estando =' DIRETO ', o merchant decodifica sozinho o token de cartas da rede. Precisa de certificados/chaves e segurança rigorosa; o uso é raro.

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

7) Fluxos de integração

7. 1 Web (passos)

1. Inicialização de um cliente de SE ay → verificação de isReadyToPay.
2. Coleta PaymentDataRequest (com redes, métodos de autenticação e toqueamento).
3. O utilizador confere (SCA) a exibição de .
4. Obter paymentMethodData (cifra) e enviar para o PSP.
5. Ответ PSP: `authorized/succeeded/failed` + webhook.
6. 'capture/refund' por necessidade; recon - por registros diários.

7. 2 Android (in-app)

Da mesma forma, você cria 'PaymentsClient', passa 'PaymentDataRequest', recebe o token e passa-o para o backand/PSP.

8) Estatais, cálculos e devoluções

Estatais on-line: 'autorized/suceeded/failed/canceled' (+ 'pending' em alguns PSP).
Senslement: Por PSP/Equeyer, normalmente T + 1/T + 2. Compartilhe o sucesso online e a contabilidade.
Refund: parcial/total de acordo com as regras de cartas.
Chargeback: procedimento de cartas (INR/NAD, etc.) permanece válido.

9) Causas frequentes de falhas (declins)

MSS/vertical (iGaming/quazi-cash) - Bloqueios seletivos em emissores/PSP.
Mismatch geo (país do mapa/IP/localização do merchant).
Configuração inválida de 'PaymentDataRequest' (redes/métodos de autenticação), 'merchantId' inválido ou modo de torneamento.
MIT sem COF/consent.
Temporizações SCA/interrupção do flow personalizado.

10) Pattern ux (o que aumenta a conversão)

Mobile-first: leve o botão Google Pay primeiro método para Android.
Um grande botão de £ ay no cartão de produto/cesta/checkout; respeite a marca hyde.
Montante pré-fill/impostos/entrega para Sheet (user-visível total).
Recovery: repetição segura em temporizações, mudança para cartões/A2A em casos de falha repetida.
Desktop↔mobayl: QR/hand-off se o usuário confirmar no telefone.

11) Rotação inteligente

Ofereça o £ ay para Android/Chrome e para BIN 's/bancos com alta aplicação.
Deslizamento de automóveis do BIN/geo específico para a degradação dos indicadores.
Para recurrentes: primeiro pagamento por meio de ay COF, seguido de MIT sem a participação do usuário.

12) Segurança e complacência

Validação de assinaturas de mensagens/ganchos da Web PSP, rigorosos 'redict/return' URI.
Chaves/segredos - em vault, IP-allowlist para callback-endpoint.
A pegada PCI é mínima em gateway-modo (você não toca PAN/segredos).
Logs: device hints, reason codes, tempo SCA/confirm.

13) iGaming: características

A disponibilidade e os limites dependem da jurisdição, do PSP e do emissor.
Espere por falhas seletivas e/ou limites reduzidos; verifique as regras locais.
Cancelamentos recorrentes - apenas MIT com COF e concordâncias documentadas do jogador.
Mantenha as alternativas A2A/open-banking, carteiras locais, eCash. Digite fallback quando você estiver em alta decline em GPay.

14) Processamento e relatórios (recon)

• 'paymentId/transactionId', 'orderId', network (Visa/MC/...), BIN/banco, montante/moeda, status/códigos de rejeição, canal (Web/In-App), timestams, ARN/UTR dos registros.

Daily auto-recon + full-recon periódico.
«Sucesso online sem registro», «dupla capture», «aging auth».

15) KPI e controle de método

Approval rate POIS ay vs mapas normais (por bancos/BIN/geo/dispositivos).
Share of SE em tráfego Android, 'retry win-rate'.
Decline matrix (reason codes), доля SCA timeouts.
Chargeback rate/ODR, settlement lag, доля partial refunds.
Regras liminares de desregulamentação automática (por exemplo, appreve <X% para um BIN/geo específico).

16) Folha de cheque de saída em proda

1. Conecta o DVDay no PSP; obtenha merchantId, configure allowedPaymentMethods/networks e tokenizationSpecification.
2. Implemente Web/In-App Sheet, 'autorize/capture/refund', webhooks (assinatura/NMAS), idempotidade e retraí.
3. Configure o COF/rede tocenization para o MIT + armazene o consent.
4. Inclua o smart-routing: prioridade para o Android, fallback para mapas/A2A.
5. Verificação de marca-gades (botões/ícones/copiar).
6. Construa recon e alertas: rashinhons, aging auth, dupla capture.
7. Testes E2E: Web/Android, partial capture/refund, temporizações/repetições, degradação PSP, carga alta.

Cartão de referência

Roteiro: cartão (Visa/MC/...); chargeback - de acordo com as regras dos cartões.
SCA: biometria/screen-lock (PSD2-compatível); O 3DS normalmente não é necessário separadamente.
Tocenização: criptograma DPAN + EMV; para o receituário - COF/rede tocen.
Статусы: `authorized/captured/succeeded/failed/refunded/voided`.
Senslement: por registro PSP (T + 1/T + 2).
Limitações: disponibilidade por dispositivo/navegador/geo; para iGaming é uma política PSP/emissores.

Currículos

Google Pay é um «acelerador» de pagamentos de cartões com alta conversão móvel e SCA integrado. Integre-se através do gateway-modo, cumpra os requisitos de PaymentDataRequest, construa em torno de webhooks + idempotidade + recon e use o COF para recredir. Para iGaming - mantenha roteiros e roteiros inteligentes alternativos, já que a disponibilidade e os limites dependem da jurisdição, banco e PSP.