Como um terminal solicita cartões

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 código de coletor. Ele é mapeado para o código do emissor de resgate no back-end do Google, com que os desenvolvedores do cartão interagem por meio da API Google Pay for Passes.

Quando ocorre um smart tap, o terminal transmite o respectivo código do coletor para o app Google Pay. O app Google Pay examina os emissores de resgate de cada cartão, deriva o código do coletor e, quando correspondente, transmite esses cartões específicos para o terminal.

Para configurá-lo, consulte Configurar smart tap para comerciantes.

Aqui está uma ilustração do processo:

Configuração 1

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 um código do coletor 12345678. Ele é mapeado para o código do coletor configurado para o emissor de resgate 1990. Todo objeto de Class_id: abc é transportado para o leitor com um código do coletor 12345678.

Configuração 1.1

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

Configuração 2: o diagrama acima mostra como a classe pode definir a 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 do 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 configurado para Issuer_id: 2018, que também é onde Class_id: abc está contido. Todo objeto de Class_id: abc é transportado para o terminal com um código do 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, os 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. Não se esqueça de verificar 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:

iLuvCoffeeEat-fooBacon-R-us
Código do emissor123456789
Código do coletor1114444444477777777
Classe de fidelidadeR-basicMinhas recompensas- nenhuma -
Classe de fidelidadeR-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ódigo do emissor de resgate do R-basic: 456, 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ódigo 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:

iLuvCoffeeEat-fooBacon-R-us
Código do emissor123456789
Código do coletor111111114444444477777777
Classe de fidelidadeR-basicMinhas recompensas- nenhuma -
Chave públicaaaabbb- 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ódigo do emissor de resgate do R-basic: 456, 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 está 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 essa 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:

  1. Atualize o saldo ou o status do usuário no PDV.
  2. Atualize o próprio back-end com base na transação no PDV.
  3. 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 via NFC. O terminal processará a descriptografia de dados depois do 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.