# Ciclo de vida de la transacción

Comprender el ciclo de vida completo de la transacción garantiza la implementación de un flujo de pago robusto y fiable. Esta página explica el viaje de extremo a extremo de un pago Tap on Phone, desde la comprobación del estado inicial del terminal hasta la determinación del resultado final de la transacción.

## El flujo de pago estándar

Una transacción de pago exitosa generalmente sigue una secuencia estándar de eventos entre tu app cliente y la app Tap on Phone.

1. **Verificación de Estado (Opcional, pero Recomendada):** Antes de iniciar un pago, tu app transmite (broadcasts) una solicitud de estado. Esto confirma que la app Tap on Phone está en el estado `Initialized`. Si el estado es `None`, debes solicitar al comercio que inicialice el POS.  
2. **Atestación Proactiva (Opcional, pero Recomendada):** Para evitar retrasos inesperados en la interfaz de usuario mientras el cliente espera, tu app transmite (broadcasts) una solicitud de atestación. Esto garantiza que el token de seguridad del dispositivo sea válido *antes* de iniciar la interfaz de pago.  
3. **Iniciación de Intent:** Tu app inicia la `POSActivity` de Tap on Phone utilizando un Android Intent. Debes pasar los detalles de la transacción (como el importe en céntimos, el tipo de transacción `PURCHASE` y tus credenciales de SSO).  
4. **Ejecución del Pago:** La app Tap on Phone toma el control de la pantalla. Solicita al cliente que acerque su tarjeta o dispositivo, lee los datos de forma segura, solicita un PIN si es necesario y se comunica con el backend para autorizar el pago.  
5. **Callback de Resultado:** Una vez finalizado el pago, la app Tap on Phone se cierra y devuelve un `ActivityResult` a tu app.

## Determinación del estado final

Cuando tu app recibe el `ActivityResult`, debes evaluar campos específicos para determinar si el pago se ha realizado correctamente.

* `RESULT_CANCELED`: El usuario canceló manualmente la transacción (por ejemplo, pulsando el botón de retroceso), o se produjo un error fatal antes de que la transacción pudiera conectarse online. No se genera ningún recibo.  
* `RESULT_OK`: El proceso de transacción se completó y se generó un recibo.

<Callout type="warning">

`RESULT_OK` no significa que el pago haya sido aprobado.** Simplemente significa que el proceso ha finalizado sin un error fatal del sistema.

</Callout>

Para determinar si el pago se ha aprobado realmente, debes inspeccionar el extra `status` devuelto dentro del intent `RESULT_OK`:

* Si `status` es `APPROVED`, el pago se ha realizado correctamente.  
* Si `status` es `DECLINED`, el pago fue denegado por el emisor o la red. Debes comprobar los campos `declineCause` y `declineError` para entender el motivo.

## Gestión de respuestas no recibidas

En entornos móviles, las aplicaciones pueden fallar (crash), o el sistema operativo Android podría cerrar tu app mientras está en segundo plano esperando a que finalice la app Tap on Phone.

Si tu app nunca recibe la respuesta del intent de transacción, no debes asumir que la transacción ha fallado. La app Tap on Phone podría haber procesado el pago correctamente mientras tu app estaba desconectada.

### El flujo de recuperación

Para recuperar un resultado de transacción no recibido, utiliza el broadcast de estado asíncrono:

1. **Capturar el ID de la Transacción:** Cuando inicias el intent de pago, la app Tap on Phone transmite un `sdkTransactionId` en cuanto comienza la transacción. Tu app debe escuchar el `TRANSACTION_BROADCAST_RESPONSE` y guardar temporalmente este UUID.  
2. **Esperar:** Si tu app pierde el resultado final, espera al menos de 5 a 10 segundos para asegurarte de que el backend ha procesado completamente la transacción.  
3. **Consultar el Estado:** Transmite un `TRANSACTION_STATUS_BROADCAST ` que contenga el UUID guardado.  
4. **Procesar el Resultado:** La app Tap on Phone responde con los detalles completos del recibo (lo que te permite comprobar si fue `APPROVED` o `DECLINED`) o con un error.

Si el broadcast de recuperación devuelve un error, recomendamos reintentarlo una vez para descartar problemas temporales de red. Si falla por segunda vez, puedes considerar de forma segura que la transacción ha sido denegada.