Getnet DocsGetnet Docs

Ciclo de vida de la transacción

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

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.

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

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.