Flujo de la transacción
Esta página detalla el flujo completo de la transacción para la integración Get Smart App2App, desde la iniciación hasta la finalización.
Resumen
La integración App2App sigue un modelo síncrono de petición-respuesta donde tu aplicación inicia una transacción, la aplicación Get Smart la procesa y el control vuelve a tu aplicación con el resultado.
Ciclo de vida de la transacción
Una transacción completa pasa por cuatro fases distintas desde la iniciación hasta la finalización. Comprender cada fase te ayudará a implementar la gestión de errores adecuada y a administrar la experiencia del usuario de forma eficaz.
Fase 1: Inicialización
Tu aplicación prepara la petición de transacción reuniendo los datos de la misma (importe, tipo, número de pedido), creando un Intent con el nombre de acción específico y añadiendo los parámetros necesarios como extras del Intent.
Fase 2: Lanzamiento
Tu aplicación lanza el Intent mediante startActivityForResult y transfiere el control a la aplicación Get Smart. Si la app Get Smart no está instalada, se lanza una excepción ActivityNotFoundException que tu aplicación debe gestionar.
Fase 3: Procesamiento
La aplicación Get Smart toma el control para mostrar la interfaz de pago, leer la tarjeta, comunicarse con los sistemas de autorización, gestionar la impresión de boletas y preparar el Intent de resultado con los detalles de la transacción.
Fase 4: Finalización
El control vuelve a tu aplicación a través del callback onActivityResult. Tu aplicación verifica el código de petición, comprueba el código de resultado para determinar si el flujo se completó o se canceló, analiza los datos de respuesta de los extras del Intent y procesa el resultado de acuerdo con tu lógica de negocio.
Diagrama de flujo detallado
El siguiente diagrama ilustra el flujo completo de la transacción, mostrando la secuencia de operaciones y el intercambio de datos entre tu aplicación y la aplicación Get Smart.
Códigos de resultado
Los resultados de las transacciones se comunican a través de dos niveles de códigos de estado: los códigos de resultado estándar de Android indican si el flujo se completó, mientras que los valores de resultado específicos de la transacción indican si el pago fue autorizado.
Códigos de resultado Android
El parámetro resultCode estándar de Android indica el estado de finalización:
| Código de Resultado | Significado |
|---|---|
RESULT_OK | La app Get Smart completó su flujo y devolvió un resultado (autorización o denegación) |
RESULT_CANCELED | El usuario canceló la operación o la app abortó el flujo |
RESULT_OK no significa que el pago haya sido autorizado. Solo significa que la app Get Smart completó su proceso. Debes comprobar el extra RESULT para determinar el estado de autorización.
Valores de resultado de la transacción
El extra RESULT en el Intent de respuesta contiene el resultado de la transacción:
| Valor | Significado |
|---|---|
"AUTORIZADA" | El pago fue autorizado |
"DENEGADA" | El pago fue denegado o falló |
Tipos de transacción
La integración App2App admite dos tipos principales de transacción, cada uno con parámetros y casos de uso específicos.
Venta
Una transacción de compra estándar donde el importe se carga en la tarjeta del cliente y se devuelve un código de autorización si tiene éxito. Establece el parámetro type en 1.
Devolución
Una devolución o anulación de una transacción anterior. Establece el parámetro type en 2 e incluye el parámetro original_order con el número de pedido de la transacción que se va a devolver.
Gestión de boletas
La impresión de boletas es gestionada íntegramente por la aplicación Get Smart, eliminando la necesidad de que tu aplicación gestione el hardware de impresión o el formato de los recibos.
Boleta del Comercio - Se imprime automáticamente tras una transacción con éxito. Contiene los detalles de la transacción y las firmas necesarias para el mantenimiento de registros.
Boleta del Cliente - La app Get Smart presenta la opción de imprimir la copia del cliente. El cliente o el comercio pueden elegir si desean imprimirla.
El callback onActivityResult se activa solo después de que se hayan completado todos los flujos de impresión.
Escenarios de error
Comprender los escenarios de error comunes te ayuda a implementar una gestión de errores robusta y proporcionar información clara a los usuarios cuando las transacciones no pueden completarse.
Aplicación no instalada - Si la app Get Smart no está instalada, Android lanza una ActivityNotFoundException. Tu app debe capturar esta excepción y mostrar un mensaje apropiado al usuario.
Transacción Denegada - Si la transacción es denegada, el resultCode será RESULT_OK, el extra RESULT será "DENEGADA", y los extras RESPCODE y ERROR_MSG contendrán los detalles de la denegación.
Cancelación por el Usuario - Si el usuario cancela la transacción, el resultCode será RESULT_CANCELED. No se intentó ninguna transacción y no se produjo ninguna autorización ni denegación.
Consideraciones de tiempo
Los tiempos de procesamiento de las transacciones varían según diversos factores, y tu aplicación debe estar diseñada para manejar estas variaciones de forma elegante.
Duración de la transacción - El tiempo varía según el método de lectura de tarjeta (el chip es más lento que el contactless), la conectividad de red, la impresión de boletas y el tiempo de interacción del usuario. Tu aplicación no debe agotar el tiempo de espera (timeout) mientras espera el resultado. El callback onActivityResult de Android siempre se activará cuando la app Get Smart finalice.
Ciclo de vida de la Activity - Mientras la app Get Smart está activa, tu Activity puede pausarse o detenerse, y el sistema puede recuperar recursos si la memoria es baja. Asegúrate de que tu Activity pueda manejar correctamente la recreación tras finalizar el pago.
Próximos pasos
- Aprende a crear un pago en Crear un pago
- Comprende cómo gestionar resultados en Gestionar resultados de la transacción
- Revisa todos los parámetros de respuesta en la Referencia de parámetros de respuesta