Getnet DocsGetnet Docs

Flujo de seguridad y atestación

Para garantizar la seguridad del entorno de ejecución y prevenir actividades fraudulentas, la app Tap on Phone depende de un mecanismo interno de atestación de seguridad. Comprender cómo funciona este proceso te ayuda a diseñar una experiencia de pago más fluida y sin retrasos para tus comercios.

¿Qué es la atestación?

Antes de que la app Tap on Phone pueda procesar un pago, debe demostrar al backend que el dispositivo Android y su entorno de ejecución son seguros y no han sido manipulados.

Para ello, la app realiza una serie de comprobaciones de seguridad. Si el dispositivo supera estas comprobaciones, el backend de Tap on Phone emite un token de atestación. Este token sirve como prueba de seguridad y es estrictamente obligatorio para cada solicitud de transacción.

El proceso automatizado en segundo plano

Dado que los tokens de atestación tienen un período de validez limitado, deben renovarse periódicamente.

La app Tap on Phone gestiona esta renovación automáticamente:

  • Tan pronto como la app se inicializa correctamente, un worker automatizado en segundo plano comienza a renovar periódicamente el token de atestación.
  • Estas comprobaciones se ejecutan completamente en segundo plano sin mostrar ninguna interfaz de usuario.
  • Este proceso automatizado se ejecuta de forma continua y solo se detiene si la sesión del POS se restablece explícitamente.

El posible retraso en la interfaz de usuario (UI)

Aunque el proceso automatizado gestiona la mayoría de los escenarios, los workers en segundo plano en Android pueden fallar ocasionalmente o ser cerrados por el sistema operativo debido a la pérdida de red, la optimización de la batería o fallos inesperados (crashes).

Si el proceso de atestación en segundo plano falla y el token de atestación actual caduca, la app Tap on Phone debe realizar una comprobación de seguridad síncrona la próxima vez que inicie una transacción.

El impacto: Cuando esto ocurre, la app Tap on Phone podría pausarse durante unos segundos para procesar la atestación antes de mostrar la interfaz de pago al comercio.

Atestación proactiva

Para evitar este posible retraso y garantizar que la interfaz de pago aparezca al instante, tu app cliente puede activar proactivamente una atestación manual mediante un Broadcast de Android.

Cuando la app cliente transmite (broadcast) esta solicitud, la app Tap on Phone intenta realizar la atestación en segundo plano de inmediato. Si la atestación actual sigue siendo válida, la app no hace nada, garantizando que no se desperdicien recursos.

Puntos de activación recomendados

Para optimizar la experiencia del comercio, recomendamos enviar un broadcast de atestación en momentos clave antes de que el proceso de pago llegue a la fase final. Los buenos puntos de activación incluyen:

  • Cuando tu app se inicia o pasa a primer plano (por ejemplo, en onStart o onResume), siempre que el POS ya esté inicializado.
  • Cuando el comercio comienza a añadir productos al carrito de compra.
  • Cuando el comercio empieza a escribir un importe en el teclado numérico (keypad).

Activar una atestación

Para activar manualmente una atestación, envía un broadcast a la app Tap on Phone utilizando la acción ATTESTATION_BROADCAST. Debes incluir el userId y el userToken para la validación 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)

Gestión de la respuesta

La app Tap on Phone emite un broadcast de respuesta una vez que finaliza la atestación en segundo plano. Puedes escuchar este broadcast para verificar el estado.

Extrae el booleano Status de los extras del intent. Si devuelve false, opcionalmente puedes inspeccionar los extras Error y ErrorMessage para la resolución de problemas.

En raras ocasiones, es posible que el broadcast de respuesta nunca se envíe. Si no recibes una respuesta tras un retraso razonable (por ejemplo, 30 segundos), debes interpretar el intento de atestación como un fallo. Puedes reintentar el broadcast una vez, pero no se recomiendan múltiples reintentos.