Getnet DocsGetnet Docs

Usar el entorno de pruebas

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

El framework Get Mini proporciona entornos específicos para desarrollo, pruebas y certificación para asegurar que las transacciones se manejen correctamente antes de salir a producción.

Requisitos

Antes de comenzar, asegúrate de tener:

  • Credenciales: Obtén credenciales de prueba (FUC y Terminal) específicamente para el entorno de integración.
  • Hardware: A diferencia de los simuladores, el SDK de Get Mini está diseñado para su uso con hardware PIN pad físico. Se requiere probar en un dispositivo físico para la conectividad Bluetooth.
  • Otros Flags de Linker: Asegúrate de que tu proyecto incluya -ObjC, -lstdc++, y -lsqlite3 en Build Settings.

Paso 1: Fijar entorno de ejecución

En el framework Get Mini, el entorno se establece globalmente usando la clase CommonUtils. Debes llamar a este método antes de cualquier otra interacción con el SDK (Login o inicialización del PIN pad).

EntornoIdentificadorDescripción
Desarrollo"des"Pruebas de desarrollo inicial.
Integración"int"Entorno de pruebas estándar para la mayoría de los integradores.
CCAL"ccal"Pruebas de pre-producción para certificación final.
Producción"real"Entorno en vivo (Por defecto si no se especifica).

Ejemplo de implementación

import CommonUtils

// Establecer al entorno de Integración (Prueba)
CommonUtils.setEntorno("int")

// Establecer tu licencia de aplicación proporcionada por Get Mini
CommonUtils.setAppLicense("TU_LICENCIA_DE_APP")

Paso 2: Lógica de pruebas (modo sin simulador)

El SDK de Get Mini no proporciona un “Lector Simulador” integrado. Si estás desarrollando en el Simulador de iOS, no podrás inicializar hardware Bluetooth.

Para probar la lógica de tu aplicación sin un dispositivo físico:

  1. Simular la Respuesta del PIN pad: Crea un envoltorio alrededor de RedsysPinpadManager que devuelva objetos ficticios RespuestaTransaccionDTO cuando la aplicación se ejecute en el simulador.
  2. Pruebas de Servicio Web: Operaciones como peticionConsultaFechaPagina o peticionDevolucion (que no requieren un PIN pad) pueden probarse directamente desde el simulador si está conectado a los entornos "int" o "des".

Paso 3: Escenarios de transacción de prueba

Los entornos de prueba (“des”, “int”, “ccal”) enrutan transacciones a pasarelas de prueba de Get Mini. Puedes simular varios resultados basados en la tarjeta de prueba utilizada o montos específicos, dependiendo de los casos de prueba proporcionados por el soporte de Get Mini.

Campos de resultado comunes a verificar:

CampoValorDescripción
Estado“F”Finalizada
Estado“G”Denegada
Estado“T”Fallo técnico
Resultado“Autorizada”Autorizada
Resultado“Denegada”Denegada
CodigoRespuestaej., 117Códigos de autorización o rechazo (ej., PIN incorrecto)

Mejores prácticas

  • Protección de Entorno: Usa flags de compilador (ej., #if DEBUG) para asegurar que el entorno "real" nunca se use durante el desarrollo.
  • Notificación de Bundle: Asegúrate de haber comunicado tu bundle a Get Mini, o el SDK fallará al autorizar incluso en entornos de prueba.
  • Protocolos de Accesorio Externo: Asegúrate de que tu Info.plist incluya los protocolos para tu hardware de prueba (ej., com.datecs.PIN pad o com.verifone.pmr.xpi).

Cambiar a producción

Cuando pases a producción:

  1. Cambia la cadena de entorno a "real".
  2. Actualiza setAppLicense con tu licencia de producción.
  3. Reemplaza los IDs de FUC y Terminal de prueba con credenciales de producción.
// Configuración de producción
CommonUtils.setEntorno("real")
CommonUtils.setAppLicense("LICENCIA_PRODUCCION")

Próximos pasos