Guia de início rápido para emissores brasileiros

Última atualização: 21/Out/2024
Versão: 1.1

Versão Descrição Data de atualização
1.1 Transações em lojas físicas via QR code passam a ser obrigatórias 21/Out/2024
1.0 Versão inicial 21/Mar/2022

Esta página esta dedicada aos Emissores brasileiros, destaca os requisitos locais mais importantes que devem ser atendidos antes de lançar uma nova integração com o Google Pay no Brasil. Ela também pode ser usada para melhorar as integrações existentes a fim de aproveitar ao máximo os recursos do Google Pay.

Requisitos locais

Provisionamento de cartão

Atualmente, existem duas maneiras de provisionar um cartão no Google Pay: Manual Provisioning e Android Push Provisioning. O Manual Provisioning (MP) refere-se a tokenizações que são, normalmente, iniciadas no aplicativo Carteira do Google, enquanto o Android Push Provisioning (PP) se refere a tokenizações que são iniciadas no aplicativo do Emissor. Mais detalhes de ambos os métodos serão abordados nas próximas seções.

Transações

No Brasil, os cartões tokenizados podem ser usados ​​para realizar transações em lojas físicas - via NFC e QR code - e também e-commerce.

Requisitos de lançamento para emissores brasileiros

Abaixo estão os requisitos locais correntes para lançar sua integração com o Google Pay no Brasil:

  1. Android Push Provisioning é obrigatório.
  2. Manual Provisioning com, no mínimo, um dos seguintes métodos Identity & Verification (ID&V): OTP SMS, OTP Email ou App-to-App, também é obrigatório.
  3. O suporte para transações em lojas físicas - via NFC e QR code - e e-commerce é obrigatório.
    • Em relação a QR code, você deve certificar sua integração com maquininhas da Cielo, Rede e Getnet que suportem pagamentos de crédito ou débito via QR code.
  4. Atenda aos critérios de saída para Android Push Provisioning e Manual Provisioning com atenção especial para:
    • Taxa de sucesso de tokenização de 90%
    • Taxa de sucesso de transação de 90%
  5. Sem problemas conhecidos conforme descrito nas seções Problemas Comuns com MP e Problemas Comuns com PP

Exemplos de integrações válidas:

  • Provisão de cartão via PP e MP com OTP SMS. Suporte para transações em lojas físicas (via NFC e QR code) e transações e-commerce
  • Provisão de cartão via PP e MP com App-to-App. Suporte para transações em lojas físicas (via NFC e QR code) e transações e-commerce
  • Provisão de cartão via PP e MP com OTP SMS, Call center. Suporte para transações em lojas físicas (via NFC e QR code) e transações e-commerce

Exemplos de integrações inválidas:

  • Provisionamento de cartão somente via MP, com OTP SMS e App-to-App como métodos de ID&V (PP ausente)
  • Provisionamento de cartão via PP e MP com Callcenter como método de ID&V (OTP SMS, OTP Email ou App-to-App ausente)
  • Provisionamento de cartão somente via PP (MP ausente)
  • Suporte para transações em lojas físicas (somente via NFC) e transações e-commerce (QR code ausente)

Manual Provisioning (MP)

Manual Provisioning refere-se a tokenizações que são, normalmente, iniciadas a partir do aplicativo Google Pay. As telas abaixo mostram um fluxo comum de usuário para adicionar um cartão ao Google Pay:

No Brasil é muito comum, durante o fluxo de tokenização via MP, ser solicitado uma etapa extra de verificação (ID&V, mostrado na tela 5 acima), levando ao fluxo de autenticação Yellow. No entanto, outros fluxos também existem, como Green e Red que, se usado com sabedoria, podem melhorar significativamente a experiência do usuário final.

Qual fluxo de autenticação devemos adotar?

Sempre que ocorrer uma tokenização, o Google Pay enviará risk scores para o TSP e o Emissor. Recomendamos que os Emissores avaliem os risk scores do Google Pay juntamente com seus sinais internos para determinar qual fluxo de autenticação deve ser retornado. Valores altos para conta e dispositivo, por exemplo, poderiam levar ao fluxo Green.

Caso o fluxo de autenticação Yellow seja retornado, um método Identity & Verification (ID&V) robusto deve ser fornecido e, no Brasil, pelo menos um dos seguintes ID&Vs deve ser implementado: OTP SMS, OTP Email ou App-to-App para que o lançamento seja aprovado.

Processo de integração

Abaixo está o processo de integração para o Manual Provisioning. Os TSPs no Brasil têm plena capacidade de orientar os Emissores nesse tipo de integração. Entre em contato com seu TSP para obter mais detalhes.

Passo Times Envolvidos Detalhes
1. Onboard Emissor & Google Emissor assina os acordos NDA / CTA e obtém acesso à Documentação para Emissor.
2. Integração Emissor & TSP TSPs e Emissores trabalham juntos para desenvolver a integração entre ambas. Mais detalhes nesse link.
3. Teste Emissor & TSP Os Emissores concluem com êxito todos os casos de teste ponta a ponta do Google Pay, trabalhando com os TSPs conforme necessário.
4. Lançamento Emissor & TSP Emissores completam os critérios de saída, e confirmam a prontidão com o TSP; O TSP notifica o Google sobre a data de lançamento. Note que o Android Push Provisioning é obrigatório no Brasil e, portanto, esse recurso também deve estar implementado antes do lançamento.

Problemas comuns com MP

Abaixo estão os problemas mais comuns enfrentados pelos Emissores durante uma integração Manual Provisioning:

Problema Comum Detalhes
Não atender às taxas de sucesso recomendadas como indicado nos critérios de saída
  • Taxa de sucesso de tokenização deve ser maior do que 90% para o fluxo de autenticação Yellow.
  • Taxa de sucesso de transação deve ser maior do que 90%.
Nome do Emissor incorreto/inconsistente nos dados do token Os nomes dos Emissores devem ser consistentes em todos os portfolios e TSPs e devem identificar claramente o Emissor pelo nome. ISO Latin characters são preferidos, mas outros tipos são permitidos desde que sejam consistentes.
Termos de Serviço, Política de Privacidade e problemas com links de sites Os Emissores devem usar links HTTPS e não podem usar links que usam Apple Pay/Samsung Pay/outras carteiras na URL. Os Emissores podem usar uma página para várias carteiras, desde que a página e a URL não façam referência a uma carteira.
Package name do aplicativo do Emissor ausente ou incorreto Emissores com um aplicativo Android devem configurar o package name corretamente em produção. Isso é requerido para Emissores que suportam o ID&V App-to-App.

Android Push Provisioning (PP)

Android Push Provisioning refere-se a tokenizações que são iniciadas no aplicativo do Emissor. As telas abaixo ilustram o fluxo do usuário:

Optimal push provisioning flow

Durante o tokenização via PP, como o usuário já está logado no aplicativo do Emissor, o fluxo de autenticação recomendado é o Green, não requerendo, portanto, algum método Identity & Verification (ID&V). Isso traz uma melhor experiência para o usuário final.

Aplicativo de exemplo, API do PP e diagramas de fluxo

O Google Pay fornece um Aplicativo de exemplo que pode ser usado, juntamente com nossa API do PP e diagramas de fluxo, para ter um conhecimento sólido sobre como integrar o aplicativo do Emissor à API do PP. Recomendamos que os times de UX e desenvolvedores verifiquem os recursos e o código desse aplicativo para que tanto o desenvolvimento quanto o lançamento sejam mais ágeis.

Processo de integração

Abaixo está o processo de integração para Android Push Provisioning. Os TSPs no Brasil têm plena capacidade de orientar os Emissores nesse tipo de integração. Entre em contato com o seu TSP para obter mais detalhes.

Passo Times Envolvidos Detalhes
1. Onboard Emissor & Google
2. Design Emissor & Google
  • Conclua a proposta de UX no aplicativo do Emissor, mostrando o todo o fluxo do PP que um usuário final faria.
  • Documente a proposta de UX e flow do usuário e envie para revisão via esse form.
  • Inclua o aplicativo do Emissor em nossa Allowlist via esse form.
3. Teste Emissor & TSP
  • Faça download do último SDK lançado aqui e configure seu ambiente. É recomendado que o desenvolvimento seja feito no ambiente sandbox.
  • Com base na API do PP, complete o desenvolvimento no aplicativo do Emissor. Trabalhe com seu TSP para gerar o OPC e para depurar qualquer erro eventualmente encontrado nessa parte.
  • Complete todos os casos de teste para validar se a implementação foi bem-sucedida.
4. Lançamento Emissor & Google
  • Envie vídeos do aplicativo do Emissor seguindo as instruções aqui executando, em produção, os seguintes casos de teste.
  • Complete os critérios de saída em produção.
  • Envie sua solicitação para Aprovação de lançamento via esse form.
  • O Google validará os resultados e, caso nenhum problema seja identificado, enviaremos a aprovação por escrito (por e-mail) autorizando o lançamento.

Problemas comuns com PP

Abaixo estão os problemas mais comuns enfrentados pelos Emissores durante uma integração Android Push Provisioning:

Problema Comum Detalhes
Como depurar o Opaque Payment Card (OPC) O Google não é capaz de solucionar problemas de OPC, pois é um objeto criptografado e apenas os TSPs sabem como construí-lo e são capazes de descriptografá-lo. No entanto, o Google Pay oferece aos desenvolvedores uma maneira de capturar a mensagem de erro durante uma tokenização. A mensagem de erro retornada pode ser enviada ao TSP para identificar o que está errado. Todos os passos para verificar o erro podem ser vistos nesse link.
Não exibir os botões do GPay com destaque e em telas com alto tráfego Para garantir que os usuários vejam o botão do Google Pay, adicione-o às telas já existentes e com alto tráfego. Certifique-se de que haja uma conexão clara entre o botão e o cartão de crédito/débito do usuário. Não exiba os botões do Google Pay em telas que não mostrem os cartões.
Exibir o botão do Google Pay apenas se o smartphone tiver NFC É incorreto pois o Google Pay também pode ser usado para pagamentos e-commerce. O NFC é necessário apenas para pagamentos por aproximação.
O aplicativo de Emissor não é capaz de resolver tokens "Yellow-pathed", levando a erros durante a tokenização Detalhes do cenário e como lidar com ele nesse link.
Aplicativo do Emissor nem sempre sincronizado com a carteira Detalhes do cenário e como lidar com ele nesse link.