Getnet DocsGetnet Docs

Seguridad y licencias

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 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
    }
}

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.

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