Adicionar suporte ao Google Pay pode parecer um processo padrão, mas existem muitas decisões que você precisa tomar e que afetam o sucesso do seu projeto de integração do Google Pay. Os atalhos técnicos podem sobrecarregar ainda mais os usuários, por isso é importante ter em mente a experiência do usuário ao planejar uma integração. Ao procurar oportunidades para otimizar a forma como seus cartões são adicionados e gerenciados na carteira do usuário, você vai ter taxas de sucesso de tokenização mais altas, maior engajamento com o cliente, muito menos chamadas no atendimento ao cliente e uma boa representação da sua marca no Google Pay.
Integrar-se com as APIs do Google Pay
O Google Pay oferece APIs que permitem que você gerencie com mais rigor a forma como seus clientes interagem com a Carteira do Google. A API Push Provisioning permite adicionar a funcionalidade da Carteira do Google ao seu próprio app ou site bancário. Muitos emissores em todo o mundo optaram pela integração com a nossa API Push Provisioning para reduzir a complexidade operacional e economizar custos oriundos da execução de sua própria carteira HCE.
Práticas recomendadas da API Push Provisioning
Para otimizar a integração da API Push Provisioning, o Google recomenda incorporar as seguintes práticas recomendadas:
Caminho verde: faça as tokenizações de provisionamento por push com o caminho verde, se possível.
Emissão instantânea: incentive os usuários a adicionar o cartão à Carteira do Google enquanto aguardam o cartão físico.
Destaque a capacidade de provisionar por push: publique banners em seu app para promover o provisionamento por push e tornar o botão de provisionamento facilmente acessível.
Para mais detalhes, consulte Práticas recomendadas de provisionamento por push.
Práticas recomendadas de ID&V
O Google aceita uma variedade de métodos de ID&V. Processos de ID&V bem pensados e de alto desempenho rendem taxas de ativação de token acima de +90% no Google Pay (consulte a lista de métodos de ID&V na ordem da taxa de ativação. O objetivo da ID&V é evitar atividades fraudulentas no dispositivo, mas, na prática, muitos usuários legítimos também são perdidos nessa etapa. Quaisquer usuários legítimos perdidos durante a ID&V não poderão usar seu cartão no Google Pay, sendo forçados a usar o cartão de outro emissor no Google Pay ou recorrer a cartões físicos. Fazer um pequeno investimento extra antecipadamente para oferecer suporte a um conjunto mais diversificado de opções de ID&V compensa significativamente em termos de adoção, segurança e redução de chamadas de suporte.
1. Aproveitar ao máximo os sinais de risco
O Google fornece vários sinais e recomendações de risco, incluindo, entre outros, pontuações de risco de contas e dispositivos, para cada um dos TSPs. Os sinais específicos dependem do TSP e dos dados que eles fornecem a você. Esses sinais podem reduzir significativamente o risco de fraude sem exigir qualquer outra interação por parte do cliente. Esses dados, além do mecanismo de risco do emissor, permitem que o emissor determine a abordagem correta de ID&V para oferecer ao usuário em cada solicitação de provisionamento. Por exemplo:
A maioria dos emissores reserva o caminho vermelho para uma taxa de risco inaceitável, que costuma ser uma fração muito pequena de tentativas.
A maioria dos emissores envia tentativas de provisionamento manual para o caminho amarelo, exceto quando se trata de um dispositivo confiável (por exemplo, configurar um novo smartphone quando o antigo já teve um token de dispositivo).
Fale com seu TSP para mais detalhes sobre os campos que eles podem fornecer para otimizar sua avaliação de risco.
2. Combinar as opções de ID&V com o nível de risco
Os emissores podem adaptar os métodos de ID&V oferecidos ao usuário com base em suas pontuações de risco de contas e dispositivos. Por exemplo, para tentativas de alto risco, os emissores poderiam optar por oferecer os métodos que consideram de maior segurança. Já para tentativas de menor risco, seria bom oferecer o pacote completo de métodos de ID&V.
3. Usar RCS para OTP por SMS
Os emissores podem garantir que a OTP seja enviada usando Serviços de Comunicação Avançada (RCS). Os chats RCS podem proporcionar uma experiência de mensagens avançada e atualizada, oferecendo mais segurança (ou seja, as mensagens enviadas entre o remetente e o usuário são criptografadas, o ID do remetente e o selo de autenticidade no cabeçalho do app). O RCS também está disponível em Wi-Fi e dados móveis.
4. Usar OTP por SMS para redirecionar o usuário pelo app bancário
Embora a verificação app-to-app esteja disponível e envolva menos atrito, como alternativa, os emissores também podem incluir um link na OTP por SMS para que o usuário se conecte ao app bancário. Uma vez no app bancário, o usuário tem a opção de completar a inscrição ou a OTP real é mostrada (ou seja, em notificações/mensagens). Em seguida, essa OTP é usada para concluir o provisionamento da Carteira do Google.
5. Práticas recomendadas gerais de mensagens para OTP por SMS e OTP por e-mail
- Se estiver usando OTP por SMS, adote RCS para oferecer uma experiência de mensagens mais avançada.
- Mencione claramente que essa é uma tentativa de adicionar um cartão à Carteira do Google.
- Reforce ao usuário que não compartilhe esse número com ninguém.
- Envie uma outra notificação de confirmação por SMS/e-mail/app ao usuário quando o cartão for adicionado à Carteira do Google. Inclua detalhes sobre como o usuário pode reportar um problema rapidamente (ou seja, se ele mesmo não tiver provisionado o cartão).
6. Métodos alternativos de ID&V que permitem que os emissores alcancem a conformidade com a SCA
A verificação app-to-app e a autenticação segura baseada na Web hospedada pelo seu TSP (consulte a ilustração abaixo) também são opções para conquistar a compliance de SCA.
Vincular novamente os tokens quando os FPANs mudarem
Quando os FPANs mudam, todos os tokens de dispositivo para esse cartão podem ser atualizados para serem vinculados ao novo FPAN. A atualização mantém o token ativo e atualiza os últimos quatro dígitos do FPAN mostrado na interface do Google Pay. A atualização pode, opcionalmente, atualizar outros atributos de metadados, como a arte do cartão. Esse recurso é muitas vezes desprezado, embora ofereça grandes benefícios ao cliente.
Por exemplo, quando o cartão de um cliente expira e um substituto é reemitido, o token criado com o cartão antigo pode ser atualizado para ser vinculado ao novo FPAN. Isso significa que os usuários não precisam passar pelo incômodo de tokenizar o cartão novamente e, possivelmente, enfrentar um novo desafio de ID&V de caminho amarelo.
Da mesma forma, quando a fraude é detectada na conta, ela geralmente não está relacionada ao token no dispositivo do usuário. Normalmente, ele se concentra no cartão físico ou em um único token. Se a fraude ocorreu no cartão físico, a antiga conta pode ser cancelada e substituída por uma nova. Também nesse caso, é possível proporcionar uma ótima experiência ao cliente vinculando novamente o token ao novo FPAN para que ele possa usar o token enquanto aguarda o envio do cartão de substituição pelo correio.
Para mais informações sobre como implementar o reposicionamento de tokens, fale com seu TSP.