# Seguridad y licencias

La lectura de la tarjeta y la introducción del PIN ocurren en el PIN pad certificado, no en tu aplicación. Esta página cubre lo que sí es responsabilidad de tu app: vincular el terminal mediante el modelo de licencias, elegir el entorno de ejecución, capturar la firma cuando la tarjeta lo exige y tratar los logs y las credenciales con cuidado.

## Vinculación de terminal y licencias

Una característica de seguridad exclusiva del SDK de Get Mini es la **Vinculación de Bundle ID**, que impide que aplicaciones no autorizadas procesen transacciones utilizando las credenciales de su comercio.

### Proceso de registro de licencia

Para utilizar el SDK, debe registrar el **Bundle Identifier** de su aplicación en Get Mini:

**Paso 1: Proporcionar el Bundle ID**

Póngase en contacto con el soporte de Get Mini y proporcione el Bundle Identifier de su aplicación iOS (se encuentra en Xcode en **General > Identity > Bundle Identifier**).

**Paso 2: Recibir la License Key**

Get Mini emite una clave de licencia vinculada de forma exclusiva a su Bundle ID específico. Esta clave vincula las credenciales de su comercio a su aplicación.

**Paso 3: Validación del SDK**

El SDK valida la licencia durante la inicialización:

```
CommonUtils.setAppLicense("YOUR_LICENSE_KEY")
```

Si el Bundle ID de la aplicación en ejecución no coincide con el asociado a la licencia, el SDK no se inicializará y devolverá un error.

### Control de entorno

Está **estrictamente prohibido** configurar el entorno a `"real"` (Producción) hasta que su implementación haya sido certificada por Get Mini:

```
// Development/Testing only
CommonUtils.setEntorno("des")  // Allowed during development

// Production - ONLY after certification
CommonUtils.setEntorno("real")  // Requires Get Mini approval
```

Este control evita transacciones de producción no autorizadas y garantiza que todas las implementaciones se sometan a una revisión de seguridad adecuada antes de procesar pagos reales.

## Firma como alternativa de seguridad

No todas las transacciones se autorizan mediante PIN. En escenarios específicos, el SDK requiere la captura de una firma digital para finalizar la validez legal de la venta.

### Cuándo se requiere la firma

Si el titular de la tarjeta no se autenticó mediante PIN, la respuesta de la transacción lo indica a través del campo `AutenticadoPorPin`:

```
func onPaymentFinished(_ result: RespuestaTransaccionDTO!, orError error: Error!) {
    if let transaction = result, transaction.AutenticadoPorPin == false {
        // Signature capture required
        captureCustomerSignature()
    }
}
```

Esto suele ocurrir con:
- **Transacciones offline** en las que no fue posible la verificación del PIN
- **Tipos de tarjeta específicos** que no admiten autenticación mediante PIN
- **Tarjetas internacionales** con requisitos de autenticación diferentes

### Envío de la firma

Su aplicación debe capturar la firma digital del cliente como una imagen y enviarla utilizando el método `envioFirmaDigitalizada`:

```
let signatureDTO = EnvioFirmaDTO(
    withTerminal: terminalDataDTO,
    withFirma: signatureImage,      // UIImage of signature
    Format: 2,                      // 2 = JPEG format
    andOperacion: operationDTO
)

RedsysConfigurationManager.envioFirmaDigitalizada(signatureDTO) { result, error in
    if error == nil {
        // Signature submitted successfully
    }
}
```

<Callout type="warning">

El envío de la firma es un **requisito de seguridad obligatorio** para completar las transacciones en las que `AutenticadoPorPin == false`. Sin la firma, la transacción puede no cumplir los requisitos de validez legal.

</Callout>

## Responsabilidades de seguridad del desarrollador

Aunque el SDK gestiona la encriptación de los datos, los desarrolladores deben cumplir las mejores prácticas de seguridad que se describen en la sección **"PRECAUCIÓN"** (Sección 3) del manual técnico.

### Protecciones de entorno

**Nunca utilice credenciales de producción en entornos de prueba:**

- Utilice `"des"` (Desarrollo), `"int"` (Integración) o `"ccal"` (Preproducción) durante el desarrollo y las pruebas
- Cambie a `"real"` (Producción) únicamente tras la aprobación de la certificación de Get Mini
- Mantenga credenciales de comercio separadas para cada entorno

### Gestión de logs

**No registre (log) datos sensibles de las transacciones:**

```
// ❌ BAD: Logs entire response object
print("Transaction result: \(result)")

// ✅ GOOD: Logs only non-sensitive fields
print("Transaction completed with status: \(result.status)")
```

Los objetos de respuesta de `onPaymentFinished` contienen metadatos de la transacción y códigos de autorización que no deben almacenarse en:
- Logs de la consola
- Logs del sistema
- Servicios de analítica externos
- Herramientas de reporte de errores (crash reporting)
- Archivos locales

### Protección de credenciales

**Proteja los identificadores del comercio:**

El FUC (Merchant ID) y los Terminal IDs deben ser:
- **Inyectados en el momento de la compilación (build)** a través de las configuraciones de build
- **Recuperados de una configuración remota segura** en tiempo de ejecución
- **Nunca codificados directamente (hardcoded) en texto plano** en el código fuente o en el control de versiones

```
// ❌ BAD: Hardcoded credentials
let fuc = "999008881"

// ✅ GOOD: Retrieved from secure configuration
let fuc = Configuration.shared.merchantFUC
```

## Próximos pasos

* [Ciclo de vida de la transacción](/es/get-mini/ios-sdk/core-concepts/ios-lifecycle) - Vea cómo los estados de seguridad hacen la transición durante una venta
* [Configurar Permisos de iOS](/es/get-mini/ios-sdk/first-steps/configure-ios-permissions) - Asegúrese de que su Info.plist está correctamente configurado