Requisitos de teste
Esperamos que os emissores testem suas integrações para garantir que os seguintes critérios sejam atendidos antes do lançamento:
- O provedor de serviços de token (TSP) aprovou seu lançamento.
- Todos os testes funcionais estão aprovados.
- O token foi adicionado com êxito em cada intervalo de BIN que está sendo lançado.
- Foram implementadas pelo menos duas opções de autenticação de caminho amarelo (ID&V).
- Dez tokenizações com taxa de sucesso de caminho amarelo acima de 80%.
- Cinco transações em lojas físicas com uma taxa de sucesso acima de 90%.
- Uma transação on-line bem-sucedida.
- (
apenas se for lançado no Brasil) 5 transações em lojas físicas - com taxa de sucesso maior que 90% - usando QR code conforme detalhado em Requisitos de lançamento para emissores brasileiros. - Nenhum problema crítico relacionado a transações em lojas físicas ou on-line.
Os emissores devem trabalhar diretamente com o TSP para certificar a integração. Os emissores não precisam solicitar a aprovação do lançamento diretamente ao Google, mas podemos bloquear um lançamento se percebermos que ele não atende a esses requisitos.
Restringir o acesso
Antes do lançamento, os usuários comuns não podem provisionar seus cartões. Trabalhe com seu TSP para restringir o acesso à tokenização somente a cartões de usuário internos e de teste autorizados até que o lançamento seja aprovado.
Teste piloto
Incentivamos (mas não exigimos) que você realize um piloto interno com funcionários antes do lançamento. O piloto ajuda a aumentar o volume de tokenizações, transações em lojas físicas, transações on-line e dispositivos em uso antes do lançamento.
Práticas recomendadas para testes
Os padrões de teste do emissor podem ser semelhantes aos padrões de fraude, uma vez que ambos normalmente envolvem a realização de muitas solicitações de provisionamento e recusas frequentes. Ao realizar testes, pode ser que você receba um bloqueio do nosso mecanismo de risco ou comece a receber pontuações de risco mais baixas do que o normal. Nossas regras de risco se aplicam a nossos ambientes de sandbox e produção.
Os casos de teste nesta página foram projetados para praticar a integração totalmente, enquanto minimizam o número geral de tentativas de tokenização necessárias para reduzir o possível impacto dos respectivos mecanismos de risco do Google e do emissor.
Teste funcional
Esperamos que os emissores realizem os seguintes testes completos para cada rede e tipos de cartões que você emitir para garantir que sua integração com o Google Pay funcione perfeitamente para os titulares de cartões:
- Criação de token
- Pagamento em lojas físicas
- Pagamento em lojas on-line
- Metadados do token
- Exclusão e suspensão
Casos de teste de criação de token
| Caso de teste | Critérios de saída |
|---|---|
| 1. Adicionar um cartão via OCR e corrigir informações | Cartão adicionado ao Google Pay |
| 2. Adicionar um cartão com inserção manual do PAN usando as informações corretas | Cartão adicionado ao Google Pay |
| 3. Tentar adicionar um cartão com validade incorreta | Mensagem de erro para avisar que o cartão não pode ser adicionado ou solicitar que o usuário verifique os detalhes inseridos. A mensagem de erro varia de acordo com a rede. |
| 4. Tentar adicionar um cartão com o CVV incorreto | Mensagem de erro para avisar que o cartão não pode ser adicionado ou solicitar que o usuário verifique os detalhes inseridos. A mensagem de erro varia de acordo com a rede. |
| 5. Tentar adicionar um cartão com o nome incorreto (se verificado pelo emissor) | Mensagem de erro para avisar que o cartão não pode ser adicionado ou solicitar que o usuário verifique os detalhes inseridos. A mensagem de erro varia de acordo com a rede. |
| 6. Tentar adicionar um cartão com o endereço incorreto (se verificado pelo emissor) | Mensagem de erro para avisar que o cartão não pode ser adicionado ou solicitar que o usuário verifique os detalhes inseridos. A mensagem de erro varia de acordo com a rede. |
| 7. Tentar adicionar um cartão com o smartphone incorreto (se verificado pelo emissor) | Mensagem de erro para avisar que o cartão não pode ser adicionado ou solicitar que o usuário verifique os detalhes inseridos. A mensagem de erro varia de acordo com a rede. |
| 8. Adicionar um cartão de caminho verde (se aceito) | Cartão adicionado ao Google Pay |
| 9. Adicionar um cartão de caminho amarelo para cada método de ID&V aceito | Cartão adicionado ao Google Pay |
| 10. Tentar adicionar um cartão não aceito (se aplicável) | Erro indicando que o cartão não pode ser usado com o Google Pay porque ainda não é aceito |
| 11. Adicionar um cartão de "usuário autorizado" (se aplicável) | Cartão adicionado ao Google Pay |
| 12. Adicionar um cartão de "titular secundário" (se aplicável) | Cartão adicionado ao Google Pay |
| 13. Tentar adicionar um cartão de caminho vermelho | Erro solicitando que o usuário entre em contato com o banco emissor do cartão Nenhuma outra ação possível. |
| 14. Adicionar o mesmo cartão ao Google Pay em outro dispositivo | Cartão adicionado ao Google Pay no segundo dispositivo. Você tem dois tokens ativos para esse cartão, um para cada dispositivo. |
Casos de teste de pagamento em lojas físicas
| Caso de teste | Critérios de saída |
|---|---|
| 1. Fazer uma transação de baixo valor em um terminal NFC aceito | Pagamento realizado |
| 2. Verificar se as notificações de transação são geradas após cada transação | A última transação é mostrada, incluindo a data, o valor e o nome do comerciante |
| 3. Reembolsar o valor total de uma compra | O reembolso foi bem-sucedido e gerou uma notificação de transação sobre o reembolso |
| 4. Reembolsar uma compra parcialmente | O reembolso parcial foi bem-sucedido e gerou uma notificação de transação sobre o reembolso |
| 5. O pagamento falha em um terminal NFC aceito quando o emissor recusa a transação (por exemplo, devido a fundos insuficientes) | A compra é recusada e o usuário recebe uma notificação de transação sobre a recusa |
| 6. Fazer uma transação de alto valor em um terminal NFC aceito | Pagamento realizado |
7. (apenas se for lançado no Brasil) Faça um pagamento com QR code em uma maquininhaCielo que suporte pagamentos de crédito ou débito usando QR code |
Pagamento bem-sucedido |
8. (apenas se for lançado no Brasil) Faça um pagamento com QR code em uma maquininha Rede que suporte pagamentos de crédito ou débito usando QR code |
Pagamento bem-sucedido |
9. (apenas se for lançado no Brasil) Faça um pagamento com QR code em uma maquininha Getnet que suporte pagamentos de crédito ou débito usando QR code |
Pagamento bem-sucedido |
10. (apenas se for lançado no Brasil) Faça um reembolso com QR code em uma maquininha Cielo que suporte pagamentos de crédito ou débito usando QR code |
Reembolso bem-sucedido |
11. (apenas se for lançado no Brasil) Faça um reembolso com QR code em uma maquininha Rede que suporte pagamentos de crédito ou débito usando QR code |
Reembolso bem-sucedido |
12. (apenas se for lançado no Brasil) Faça um reembolso com QR code em uma maquininha Getnet que suporte pagamentos de crédito ou débito usando QR code |
Reembolso bem-sucedido |
Casos de teste de pagamento em lojas on-line
| Caso de teste | Critérios de saída |
|---|---|
| 1. Fazer uma transação em loja on-line e verificar se ela foi bem-sucedida | Pagamento realizado |
| 2. Verificar se uma notificação é exibida após a transação | São exibidos os detalhes da transação, incluindo data, valor e nome do comerciante |
| 3. Verificar se o recibo é exibido corretamente para essa transação. | São exibidos os detalhes da transação, incluindo data, valor e nome do comerciante |
Casos de teste de metadados de token
| Caso de teste | Critérios de saída |
|---|---|
| 1. Verificar a arte do cartão na tela de ID&V do caminho amarelo | A arte correta do cartão é mostrada |
| 2. Verificar a arte do cartão para saber se há tokens ativos | A arte correta do cartão é mostrada |
| 3. Verificar o link do app na tela de detalhes do cartão | O link para seu app está visível e correto |
| 4. Verificar o link Termos de Serviço na tela de detalhes do cartão | O link para seus Termos de Serviço está visível e correto |
| 5. Verificar o link da Política de Privacidade na tela de detalhes do cartão | O link para sua Política de Privacidade está visível e correto |
| 6. Verificar o telefone de contato na tela de detalhes do cartão | As informações telefônicas de contato estão visíveis e corretas |
| 7. Atualizar os metadados do cartão (por exemplo, arte do cartão, link da política de privacidade etc.) | As atualizações são aplicadas ao token |
Casos de teste para vincular token novamente
| Caso de teste | Critérios de saída |
|---|---|
| 1. Atualizar o PAN do cartão | Verificar se os últimos quatro dígitos estão atualizados no token |
| 2. Fazer uma transação NFC usando o cartão com o PAN atualizado | Pagamento realizado |
Casos de teste de exclusão e suspensão
| Caso de teste | Critérios de saída |
|---|---|
| 1. Excluir token no Google Pay | O cartão foi removido da lista de cartões no Google Pay e a exclusão é visível no sistema de back-end do emissor |
| 2. Excluir token usando o back-end do emissor | O cartão foi removido da lista de emissor cartões no Google Pay em um curto espaço de tempo (de preferência, alguns segundos) |
| 3. Suspender o token usando o back-end do emissor (se aplicável) | O cartão mostra um status suspenso em pouco tempo (de preferência alguns segundos) |
| 4. Cancelar suspensão usando o back-end do emissor (se aplicável) | O cartão para de indicar um status suspenso em pouco tempo (de preferência alguns segundos) |
| 5. Suspender o cartão usando o back-end do emissor | Há duas saídas possíveis para esse back-end do emissor teste. O comportamento varia de acordo com o emissor. Opção 1: o cartão é suspenso, mas o token permanece ativo para fazer compras. Opção 2: o cartão é suspenso e todos os tokens também são suspensos. |
| 6. Cancelar suspensão do cartão usando o back-end do emissor | O cartão para de indicar um status suspenso pouco tempo depois de ter sido reativado (de preferência alguns segundos) |
| 7. Tentar adicionar um cartão que está suspenso | A tentativa de provisionamento é recusada pelo emissor (caminho vermelho) |
| 8. Tentativa de adicionar um cartão que foi anteriormente suspenso e reativado | A tentativa de provisionamento segue o cenário de tokenização do caminho verde ou amarelo normalmente |
| 9. Faça uma transação NFC usando o token que foi suspenso e reativado anteriormente | Pagamento realizado |
| 10. Faça uma transação on-line usando o token que foi suspenso e reativado anteriormente | Pagamento realizado |