Getnet DocsGetnet Docs

Seguridad y enlace de dispositivos

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

La seguridad en el Get Mini Android SDK se logra delegando todas las operaciones de pago sensibles a un PIN pad externo certificado y aplicando una asociación de terminal controlada a través de flujos de autenticación y activación gestionados por el backend. La aplicación Android actúa únicamente como un controlador host y nunca maneja datos sin procesar de tarjetas o claves criptográficas.

Este documento describe los mecanismos reales de seguridad y asociación implementados por el Get Mini Android SDK, basados en el sistema de Login y Login Transparente (activación de dispositivo).

Modelo de asociación de terminal

El modelo de seguridad del Get Mini Android SDK garantiza que cada configuración de terminal (identificadores de comercio y terminal) solo pueda ser operada por dispositivos y usuarios autorizados. Esto previene el uso no autorizado de credenciales de comercio y aplica responsabilidad para todas las transacciones procesadas a través del SDK.

La asociación de terminal en el Get Mini Android SDK es administrativa y lógica, no basada en hardware. Es gestionada por el backend y aplicada a través de procedimientos controlados de Login y activación.

Identificadores de terminal

Cada terminal de Get Mini se identifica por dos parámetros obligatorios:

  • FUC (Identificador único del Comercio): Identifica únicamente al comercio dentro del sistema de autorización (por ejemplo, un código de comercio único).
  • Número de Terminal: Identifica un terminal lógico específico bajo la cuenta del comercio (valores del 1 al 99).

Los metadatos adicionales del terminal incluyen:

  • NSerie: Número de serie del terminal.
  • Type: Tipo de terminal (Virtual = 1, PC = 2).
  • Csb: Entidad del terminal.
  • Currency: Código numérico de moneda (por ejemplo, 978).
  • CurrencyCode: Código alfanumérico de moneda (por ejemplo, «EUR»).

Estos identificadores se asignan durante la incorporación del comercio y se devuelven a la aplicación como parte de la respuesta de Login en objetos RedCLSTerminalData. Todas las operaciones de pago requieren una combinación válida de FUC y Número de Terminal.

Autorización de dispositivo y vinculación de Login

Antes de que un terminal pueda usarse en un dispositivo Android, debe estar explícitamente autorizado a través de los mecanismos de Login del Get Mini Android SDK.

El SDK admite los siguientes flujos de autorización:

Login

El método de Login estándar autentica a los usuarios con nombre de usuario y contraseña:

RedCLSLoginSsmResponse response =
    RedCLSMerchantConfigurationManager.login(loginData);

Esto devuelve:

  • Una lista de comercios (RedCLSMerchantData) a los que el usuario tiene acceso.
  • Para cada comercio, una lista de terminales (RedCLSTerminalData) disponibles para operaciones.
  • Metadatos del usuario (vencimiento de contraseña, tipo de usuario).

La aplicación no puede realizar operaciones de pago sin un Login exitoso y una selección de terminal válida.

Login Transparente (activación de dispositivo)

El Login Transparente permite que un dispositivo opere terminales sin requerir nombre de usuario/contraseña en cada inicio. Este es un proceso de tres pasos:

1. Solicitud de activación inicial

Después de un Login exitoso basado en credenciales, la aplicación puede solicitar la activación del dispositivo para terminales específicos:

RedCLSLoginTransLoginResponse response =
    RedCLSMerchantConfigurationManager.autoLogin(context, autoLoginData);

El objeto RedCLSLoginTransAutoLoginData contiene:

  • La lista de terminales a activar (List<RedCLSTerminalData>).
  • Los datos y respuesta de Login originales.
  • Una bandera de notificación por correo electrónico opcional (típicamente false).

Esto crea una solicitud de activación de dispositivo que debe ser aprobada por el administrador del comercio.

2. Aprobación del administrador

El administrador del comercio recibe la solicitud de activación y debe aprobarla explícitamente a través del portal backend. Hasta la aprobación, el dispositivo no puede usar el Login Transparente.

3. Inicios de sesión posteriores sin credenciales

Una vez aprobado, el dispositivo puede recuperar datos del terminal en inicios posteriores sin credenciales:

RedCLSLoginTransLoginResponse response =
    RedCLSMerchantConfigurationManager.loginWithoutUser(context);

Esto devuelve la misma estructura de datos del terminal que el Login basado en credenciales, permitiendo que la aplicación proceda con operaciones de pago.

Añadir terminales adicionales

Después de la activación inicial, se pueden añadir terminales adicionales a un dispositivo ya activado. Para ello, crea un objeto RedCLSLoginTransPetNuevoTerminal indicando Fuc (identificador del comercio), Terminal (número de terminal) y Type (tipo de terminal) del nuevo terminal a dar de alta.

ResponseData response =
    RedCLSMerchantConfigurationManager.addTerminal(context, terminalData);

Esto requiere aprobación del administrador antes de que el nuevo terminal aparezca en las respuestas posteriores de loginWithoutUser().

Desactivar el Login Transparente

Para eliminar la autorización del dispositivo:

RedCLSMerchantConfigurationManager.disableLoginTrans(context);

Esto desvincula el dispositivo de todos los terminales activados, requiriendo un nuevo proceso de activación para restaurar el acceso.

Gestión de claves criptográficas

En la arquitectura del Get Mini Android SDK, todas las operaciones criptográficas se ejecutan en el PIN pad externo.

Las siguientes operaciones:

  • Captura de datos de tarjeta (EMV, sin contacto, banda magnética).
  • Entrada y verificación de PIN.
  • Procesamiento de transacciones EMV.
  • Cifrado y uso seguro de claves.

se realizan completamente dentro del hardware certificado del PIN pad.

Almacenamiento y carga de claves

Las claves criptográficas se almacenan en “cajones” seguros dentro del PIN pad. Durante la inicialización (inicializarPinpad()), el SDK informa:

  • estadoUltimaCargaClaves: Estado de la última operación de carga de claves.

    • 0 = No se cargaron claves en el PIN pad.
    • 1 = Claves cargadas correctamente.

  • Cajones: Lista de cajones de claves disponibles, cada uno conteniendo:

    • Información de versión de clave (CI, CA, CTC, CPIN).
    • Valores de control para cada tipo de clave.
    • Estado de carga de clave (0 = cargada correctamente, 1 = no cargada).

Si se requieren actualizaciones de claves, el SDK las maneja de forma transparente durante la inicialización. La aplicación nunca accede ni gestiona estas claves directamente.

Qué maneja tu aplicación

Como resultado de esta arquitectura:

  • La aplicación Android nunca accede a datos sin procesar de tarjetas.
  • No existen claves de cifrado en el proceso de la aplicación o en el almacenamiento del dispositivo.
  • La aplicación solo recibe números de tarjeta enmascarados e identificadores de transacción adecuados para recibos y mantenimiento de registros.

Mejores prácticas de seguridad

Al implementar el SDK de Get Mini Android, sigue estas pautas:

  • Nunca almacenes ni registres datos de tarjetas. Usa solo los valores enmascarados e identificadores devueltos en RedCLSTransactionData (por ejemplo, números de tarjeta enmascarados, códigos de autorización, referencias de transacción).
  • Aplica autenticación de usuario dentro de tu aplicación antes de permitir operaciones de pago.
  • Separa los entornos estrictamente. Usa terminales de integración o certificación (CCAL) para desarrollo y pruebas, y terminales de producción solo en entornos en vivo.
  • Maneja los códigos de error explícitamente. Siempre evalúa el campo status y los códigos de error de RedCLSErrorCodes antes de asumir un resultado de transacción.
  • Mantén el SDK actualizado para beneficiarse de correcciones de seguridad y actualizaciones de protocolo.
  • Protege las credenciales de Login. Nunca codifiques nombres de usuario o contraseñas en el código de tu aplicación.
  • Usa el Login Transparente con cuidado. Solo activa terminales de producción en dispositivos de producción, ya que la desactivación requiere acción administrativa.

Consideraciones de entorno

El Get Mini Android SDK admite múltiples entornos de ejecución, configurados a través de:

RedCLSConfigurationLibrary.setiEntorno(environment);

Entornos disponibles:

  • ENTORNO_DESARROLLO: Desarrollo (reservado para Redsys).
  • ENTORNO_INTEGRACION: Pruebas de integración.
  • ENTORNO_CCAL: Entorno de certificación.
  • ENTORNO_REAL: Producción.

Cada entorno tiene su propio:

  • Configuraciones y credenciales de terminal.
  • Sistemas de autorización backend.
  • Infraestructura de gestión de claves.

Las asociaciones de terminal son específicas del entorno y no se pueden reutilizar entre entornos.

Siempre usa credenciales que no sean de producción durante el desarrollo y las pruebas. Activar terminales de producción en dispositivos de desarrollo puede requerir intervención administrativa para deshacer.

Durante el desarrollo, siempre inicializa el SDK con entornos que no sean de producción para evitar la vinculación accidental o el procesamiento de transacciones en vivo.

Recursos relacionados