Getnet DocsGetnet Docs

Fluxo de Segurança e Atestação

Para garantir a segurança do ambiente de execução e evitar atividades fraudulentas, o aplicativo Tap on Phone depende de um mecanismo interno de atestação de segurança. Entender como esse processo funciona ajuda você a projetar uma experiência de checkout mais fluida e sem atrasos para os seus lojistas.

O que é Atestação?

Antes que o aplicativo Tap on Phone possa processar um pagamento, ele deve provar ao backend que o dispositivo Android e seu ambiente de execução são seguros e não foram adulterados.

Para fazer isso, o aplicativo realiza uma série de verificações de segurança. Se o dispositivo passar nessas verificações, o backend do Tap on Phone emite um token de atestação. Este token serve como uma prova de segurança e é estritamente obrigatório para toda solicitação de transação.

O Processo Automatizado em Segundo Plano

Como os tokens de atestação têm um período de validade limitado, eles devem ser renovados regularmente.

O app Tap on Phone gerencia essa renovação automaticamente:

  • Assim que você inicializa o aplicativo com sucesso, um worker automatizado em segundo plano começa a renovar periodicamente o token de atestação.
  • Essas verificações são executadas totalmente em segundo plano, sem exibir nenhuma interface de usuário.
  • Este processo automatizado é executado continuamente e só para se a sessão do POS for redefinida explicitamente.

O Possível Atraso na UI

Embora o processo automatizado gerencie a maioria dos cenários, os workers em segundo plano no Android podem ocasionalmente falhar ou ser encerrados pelo sistema operacional devido a perda de rede, otimização de bateria ou falhas inesperadas (crashes).

Se o processo de atestação em segundo plano falhar e o token de atestação atual expirar, o app Tap on Phone deverá realizar uma verificação de segurança síncrona na próxima vez que você iniciar uma transação.

O impacto: Quando isso acontece, o aplicativo Tap on Phone pode pausar por alguns segundos para processar a atestação antes de exibir a UI de pagamento para o lojista.

Atestação Proativa

Para evitar esse possível atraso e garantir que a UI de pagamento apareça instantaneamente, o seu aplicativo cliente pode acionar proativamente uma atestação manual usando um Broadcast do Android.

Quando você transmite (broadcast) essa solicitação, o app Tap on Phone tenta realizar a atestação em segundo plano imediatamente. Se a atestação atual ainda for válida, o app não faz nada, garantindo que nenhum recurso seja desperdiçado.

Pontos de Acionamento Recomendados

Para otimizar a experiência do lojista, recomendamos enviar um broadcast de atestação em momentos-chave antes que o fluxo de checkout chegue à etapa de pagamento. Bons pontos de acionamento incluem:

  • Quando o seu aplicativo é iniciado ou trazido para o primeiro plano (ex: em onStart ou onResume), desde que o POS já esteja inicializado.
  • Quando o lojista começa a adicionar produtos ao carrinho de compras.
  • Quando o lojista começa a digitar um valor no teclado numérico (keypad).

Acionando uma Atestação

Para acionar manualmente uma atestação, envie um broadcast para o aplicativo Tap on Phone usando a action ATTESTATION_BROADCAST. Você deve incluir o userId e o userToken para a validação de SSO.

val intent = Intent().apply {
    action = "com.dejamobile.cbp.sps.ATTESTATION_BROADCAST"
    component = ComponentName(
        "com.dejamobile.cbp.sps.app",
        "com.dejamobile.cbp.sps.app.broadcast.AttestationBroadcastReceiver"
    )
    addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES)

    // Mandatory SSO parameters
    putExtra("userId", userId)
    putExtra("userToken", userToken)

    // Optional: Define a custom response broadcast action
    putExtra("ResponseAction", "my.custom.broadcast.name.ATTESTATION_RESPONSE")
}

// Fire the broadcast
sendBroadcast(intent)

Gerenciando a Resposta

O app Tap on Phone emite um broadcast de resposta assim que a atestação em segundo plano é concluída. Você pode escutar este broadcast para verificar o status.

Extraia o booleano Status dos extras do intent. Se ele retornar false, você pode opcionalmente inspecionar os extras Error e ErrorMessage para solução de problemas.

Em casos raros, o broadcast de resposta pode nunca ser enviado. Se você não receber uma resposta após um atraso razoável (por exemplo, 30 segundos), você deve interpretar a tentativa de atestação como uma falha. Você pode tentar reenviar o broadcast uma vez, mas múltiplas tentativas não são recomendadas.