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
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 Google Pay, 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.
Abaixo estão os requisitos locais correntes para lançar sua integração com o Google Pay no Brasil:
- Android Push Provisioning é obrigatório.
- 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.
- 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%
- Sem problemas conhecidos conforme descrito nas seções Problemas Comuns com MP e Problemas Comuns com PP
Exemplos de integrações válidas:
- PP + MP com OTP SMS
- PP + MP com App-to-App
- PP + MP com OTP SMS, Callcenter
Exemplos de integrações inválidas:
- Somente MP, com OTP SMS e App-to-App como métodos ID&V (está faltando PP)
- PP + MP com Callcenter como método ID&V (está faltando OTP SMS, OTP Email ou App-to-App)
- Somente PP (está faltando MP)
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 |
|
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. |
Links recomendados
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:
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 |
|
3. Teste | Emissor & TSP |
|
4. Lançamento | Emissor & Google |
|
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 online. 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. |