Há várias maneiras do terminal de um comerciante solicitar um cartão específico.
Comunicação entre um terminal e o app Google Pay
Um terminal se identifica com um ID de coletor. Ele é mapeado para o ID do emissor de resgate no back-end do Google, com que os desenvolvedores do cartão interagem pela API Google Pay for Passes.
Quando ocorre um smart tap, o terminal transmite seu ID de coletor ao app Google Pay. O app Google Pay examina os emissores de resgate de cada cartão, deriva o ID do coletor e, quando há correspondência, transmite esses cartões específicos para o terminal.
Para configurar isso, consulte Configurar um terminal de comerciante.
Aqui está uma ilustração do processo:
Configuração 1: no diagrama acima, Issuer_id: 2018 tem uma classe e um objeto. Essa conta do emissor é usada pelo desenvolvedor do cartão. A classe Class_id: abc tem um objeto redemptionIssuers['1990']. Por definição, Issuer_id: '1990' é um código do emissor de resgate que representa o comerciante fooPizza. O terminal tem o código do coletor 12345678.
Ele é mapeado para o código do coletor configurado para o emissor de resgate 1990. Qualquer objeto de Class_id: abc é enviado ao leitor com o código de coletor 12345678.
Configuração 1.1: no exemplo acima, fooPizza e yumPie podem resgatar o mesmo cartão, object_id: 123. Uma classe pode ter vários emissores de resgate. As contas do emissor de resgate correspondentes aos emissores têm os próprios códigos de coletores exclusivos nos respectivos terminais.
Configuração 2: o diagrama acima mostra como a classe pode definir sua própria conta do emissor para ser um emissor de resgate. Issuer_id: 2018 tem uma classe e um objeto. A classe Class_id: abc tem um objeto emissor de resgate chamado Issuer_id: 2018. Por definição, Issuer_id: 2018 é um código do emissor de resgate, que representa o comerciante fooPizza. O terminal tem o código do coletor 12345678. Ele é mapeado para o código do coletor que está configurado para Issuer_id: 2018, que também é onde está o Class_id: abc. Qualquer objeto de Class_id: abc é encaminhado para o terminal com o código de coletor 12345678.
Seleção do usuário pelo app Google Pay
O comportamento do que é transmitido para o app Google Pay depende do que o usuário vê no respectivo dispositivo.
Se um usuário visualizar o cartão no Google Pay e, em seguida, usa smart taps, esse cartão será transmitido, desde que o código do coletor corresponda ao terminal que o solicita. Ele faz isso independentemente da validade, que se baseia nas propriedades definidas na classe ou no objeto.
O usuário talvez não veja o cartão, como quando está na guia inicial do Google Pay ou quando o visualiza na exibição de tela desbloqueada no dispositivo. Se o usuário não vir o cartão e só tiver um cartão resgatável válido com base no código do coletor, o cartão será transmitido.
Se o usuário tiver muitos cartões válidos e resgatáveis com base no código do coletor, o Google Pay realizará uma das seguintes tarefas:
- Exibirá um carrossel de seleção para o usuário escolher e tocar para transmitir.
- Ou, se houver apenas um cartão válido, ele o transmitirá.
A validade de um cartão depende da indústria. Verifique as propriedades relacionadas ao estado e à data de uso, como object.state ou object.validTimeInterval.
Exemplo de coleção de smart taps
Considere este exemplo de configuração de emissores falsos e os respectivos programas de fidelidade:
| iLuvCoffee | Eat-foo | Bacon-R-us | |
|---|---|---|---|
| Código do emissor | 123 | 456 | 789 |
| Código do coletor | 111 | 44444444 | 77777777 |
| Classe de fidelidade | R-basic | Minhas recompensas | - nenhuma - |
| Classe de fidelidade | R-gold | - nenhuma - | - nenhuma - |
O iLuvCoffee tem duas classes de fidelidade diferentes usadas para criar cartões: os programas R-basic e R-gold. Enquanto isso, o Eat-foo tem o próprio programa Minhas recompensas, e o Bacon-R-us não tem programas de fidelidade.
Agora, suponhamos que você gostaria da seguinte configuração:
- R-basic é resgatável no Eat-foo e no Bacon-R-us.
- Minhas recompensas é resgatável no Eat-foo.
- R-gold não tem suporte para smart tap.
Para essa configuração, as classes de fidelidade são configuradas com estes códigos de emissores de resgate:
- Códigos do emissor de resgate do R-basic: 456 e 789
- Código do emissor de resgate do Minhas recompensas: 456
- Código do emissor de resgate do R-gold: - nenhum -
Com essa configuração, as instâncias dessas classes têm estes códigos de coletores configurados:
- Códigos do coletor do R-basic: 44444444 e 77777777
- Código do coletor do Minhas recompensas: 44444444
- Código do coletor do R-gold: - nenhum -
Autenticação do coletor no momento do smart tap
Cada conta do emissor pode ter um número qualquer de chaves de segurança pública associadas a ela. Essas chaves públicas acabam sendo sincronizadas e armazenadas no app Google Pay e estarão prontas para uso caso o usuário toque em um terminal referente a um dos códigos de coletores associados.
Para continuar o exemplo, suponhamos que nossos emissores também tenham estas chaves configuradas:
| iLuvCoffee | Eat-foo | Bacon-R-us | |
|---|---|---|---|
| Código do emissor | 123 | 456 | 789 |
| Código do coletor | 11111111 | 44444444 | 77777777 |
| Classe de fidelidade | R-basic | Minhas recompensas | - nenhuma - |
| Chave pública | aaa | bbb | - nenhuma - |
O usuário tem o cartão de fidelidade R-basic do iLuvCoffee e um cartão de fidelidade Minhas recompensas do Eat-foo na respectiva conta do Google Pay e tenta um smart tap em terminais diferentes.
Estes são os conjuntos de emissores de resgate dessas duas classes de cartão de fidelidade:
- Códigos do emissor de resgate do R-basic: 456 e 789
- Código do emissor de resgate do Minhas recompensas: 456
Aqui estão três resultados possíveis:
Terminal iLuvCoffee: o aplicativo do Google Pay pode, teoricamente, autenticar e confirmar que o terminal realmente pertence ao iLuvCoffee. No entanto, o iLuvCoffee não está configurado para resgatar o emissor da própria classe de fidelidade, R-basic. Assim, neste caso, nada é transmitido.
Terminal Eat-foo: o aplicativo do Google Pay autentica o terminal Eat-foo que usa a chave pública "bbb". Se presumimos que a tela detalhada de um cartão R-basic ou Minhas recompensas não esteja visível para o usuário, como quando ele está visualizando a guia inicial, o aplicativo procurará cartões resgatados pelo Eat-foo. Ele encontra um cartão R-basic e um cartão Minhas recompensas e carrega um carrossel para que o usuário possa selecionar e tocar no cartão que quiser transmitir.
Ou se o usuário visualizar R-basic e tentar um smart tap, somente R-basic será transmitido.
Terminal Bacon-R-us: não há chave pública para o Bacon-R-us nesta plataforma. Portanto, mesmo que o cartão R-basic o identifique como emissor resgatável, ele não poderá autenticar o terminal. Consequentemente, nada será transmitido.
Limites de autenticação
Quando um cartão é sincronizado com o app Google Pay, todos os emissores de resgate dele são pesquisados no back-end do Google. O código do coletor, as chaves públicas e as versões de chave que correspondem a cada emissor são armazenados localmente no app Google Pay para esse cartão.
Pode haver muitas chaves públicas e versões de chave para um único código de coletor. Um cartão pode ter muitos códigos de emissor de resgate, que têm um mapeamento de um para um com um código de coletor.
O app Google Pay não autenticará um terminal se não houver cartões resgatáveis por esse terminal. Essa informação é identificada pelo código do coletor e pela versão da chave solicitada. Para atualizar as chaves públicas de um cartão, o dispositivo precisa estar conectado à Internet. Assim, ele pode recuperar as novas chaves públicas do back-end do Google.
Um cartão pode ser associado a muitas chaves públicas de uma só vez. Consulte Ativar o smart tap para um comerciante se você quiser definir várias chaves públicas para o mesmo cartão.
Valor transmitido pelo cartão
O objeto de cada indústria precisa definir esta propriedade de string: object.smartTapRedemptionValue.
Assim que a classe correspondente ao objeto estiver ativada para o smart tap, esse valor será enviado para o terminal.
Com base na integração com o PDV, use esse valor para identificar o cartão do usuário e siga estas ações depois que ele realizar um smart tap com êxito no terminal de um comerciante:
- Atualize o saldo ou o status do usuário no PDV.
- Atualize seu back-end com base na transação no PDV.
- Emita uma atualização para o objeto. Dessa maneira, isso se reflete no cartão do Google Pay.
O terminal e o app Google Pay processam a criptografia de todos os dados transmitidos por NFC. O terminal processa a descriptografia de dados após o smart tap. Dentro dos dados, há registros NDEF do objeto de serviço que representam cada cartão transmitido. O Service number NDEF Record do objeto de serviço tem um payload que contém o valor definido no object.smartTapRedemptionValue do cartão. Isso significa que o desenvolvedor do cartão não precisa criptografar nada. Se o desenvolvedor do cartão quiser criptografia extra para ainda mais segurança, defina o valor de maneira que somente o sistema PDV possa descriptografá-lo. O processo de criptografia é responsabilidade do desenvolvedor do cartão e do contato do PDV.