Entorno de pruebas (Sandbox)
El entorno de pruebas (sandbox) de Cardflo permite a los desarrolladores integrar y probar soluciones de pago sin afectar las transacciones en vivo.
Este espacio aislado replica nuestro entorno de producción, lo que permite realizar pruebas exhaustivas de todas las funciones de Cardflo, desde el procesamiento de pagos hasta los webhooks y las interacciones de la API, garantizando una transición fluida a las operaciones en vivo.
- Categoría
- Desarrollador
- Capacidades
- 10
- Disponible en
- Todos los planes
La visión general
Un entorno de pruebas (sandbox) actúa como una instancia no productiva de una pasarela de pago o plataforma de orquestación, lo que permite a los desarrolladores modelar todo el ciclo de vida de la transacción sin mover fondos reales.
Opera como una réplica de la API en vivo, incluyendo componentes para autorización, captura y liquidación. Dentro de este contenedor aislado, los equipos técnicos pueden verificar su lógica de integración, estructuras de solicitud y encabezados de autenticación contra estrictas reglas de validación.
Al usar credenciales de prueba y números de identificación de tarjeta (BIN) simulados, los comerciantes pueden evaluar cómo reacciona su backend a varias respuestas, como pagos exitosos, denegaciones suaves o solicitudes de autenticación 3DS.
El sandbox se encuentra entre la aplicación del comerciante y el adquirente simulado, proporcionando un espacio seguro para garantizar que el código maneje casos extremos, como fondos insuficientes o tarjetas caducadas,
antes de pasar a un entorno de producción en vivo donde los errores podrían resultar en pérdida de ingresos o mayores tasas de contracargos.
Cómo funciona
Generación y autenticación de credenciales
Los desarrolladores obtienen un conjunto específico de claves API o tokens Bearer designados para el entorno de pruebas. Estas credenciales dirigen las solicitudes a un procesador simulado en lugar de a los esquemas de pago en vivo.
Esto garantiza que ningún número de identificación de comerciante (MID) sea facturado por las tarifas de procesamiento y que ningún dato real del titular de la tarjeta ingrese a los sistemas de producción.
Procesamiento de transacciones simuladas
El comerciante envía una solicitud de pago utilizando números de tarjeta de prueba predefinidos que activan resultados específicos. Por ejemplo, usar un BIN podría simular una autorización exitosa, mientras que otro activa una falta de coincidencia de CVV o una denegación dura.
El sandbox devuelve una estructura de respuesta JSON idéntica a la API en vivo para garantizar la compatibilidad.
Notificación de eventos de webhook
Una vez que el estado de una transacción cambia en el sandbox, el sistema genera webhooks asincrónicos. El servidor del comerciante recibe estas notificaciones en un punto final designado para verificar que su sistema actualiza correctamente la base de datos interna.
Este paso es fundamental para probar la lógica de cumplimiento automático de pedidos o la gestión de suscripciones en tiempo real.
Cambio de estado y liquidación
Los usuarios pueden transicionar manual o programáticamente el estado de una transacción de autorizada a liquidada o reembolsada dentro del panel de pruebas.
Esto permite la verificación de los flujos de trabajo posteriores a la compra, incluido el manejo de solicitudes de recuperación o reembolsos parciales, asegurando que la interfaz de usuario del comerciante refleje el estado financiero correcto.
Por qué importa
Mitigación de riesgos durante la implementación
Implementar nuevos flujos de pago directamente en producción crea un alto riesgo operativo. Al utilizar un sandbox, los desarrolladores pueden identificar errores lógicos o solicitudes de API mal formadas que de otro modo conducirían a pagos fallidos.
Este aislamiento protege la integridad del Número de Identificación de Comerciante en vivo y evita activaciones accidentales de filtros antifraude que podrían ocurrir durante pruebas agresivas de la lógica de integración de tarjetas presentes o no presentes.
Validación de lógica compleja
Los pagos modernos a menudo implican procesos de varios pasos como la Autenticación Reforzada de Cliente (SCA) o la facturación recurrente.
Un sandbox permite realizar pruebas rigurosas de transacciones iniciadas por el titular de la tarjeta y por el comerciante sin el costo financiero de las transacciones reales.
Garantiza que el sistema interprete correctamente varios códigos de denegación y mensajes de respuesta de los emisores, lo que permite el refinamiento de la lógica de cobro y las estrategias de reintento para optimizar las tasas de conversión finales.
Casos de uso
Integración inicial de la API
Los nuevos comerciantes utilizan el sandbox para mapear sus sistemas internos de gestión de pedidos a los puntos finales de la API de la pasarela de pago.
Esto confirma que los campos de datos como los códigos de moneda y los códigos de categoría de comerciante tienen el formato correcto para la autorización.
Verificación de facturación recurrente
Las empresas basadas en suscripciones prueban sus secuencias de cobro simulando la caducidad de la tarjeta o fondos insuficientes. Esto garantiza que el sistema intente reintentos correctamente y envíe notificaciones apropiadas al cliente antes de la suspensión del servicio.
Depuración de puntos finales de webhook
Los desarrolladores utilizan el entorno de pruebas para verificar que su firewall y las configuraciones del servidor permitan las notificaciones de webhook entrantes. Esto evita problemas en los que los pedidos permanecen 'pendientes' a pesar de la autorización exitosa a nivel del adquirente.
Pruebas de métodos de pago alternativos
Antes de habilitar los métodos de pago locales, los comerciantes pueden simular los flujos de redirección necesarios para los APM. Esto garantiza que la experiencia del usuario siga siendo consistente cuando el cliente es enviado a una billetera o portal bancario de terceros.
En cifras
Ganancias de eficiencia típicas observadas por los equipos técnicos al utilizar un sandbox completo en comparación con la revisión manual de la documentación y las pruebas directas de producción.
Rango estimado de reducción de errores posteriores a la implementación relacionados con la lógica de pago cuando se implementan pruebas rigurosas en el sandbox como parte del pipeline de CI/CD.
Tiempo de respuesta estándar de la industria para los puntos finales de la API simulados, lo que permite una rápida iteración durante el ciclo de vida del desarrollo de software.
Términos relacionados
Talk to our team about a live rollout on your acquiring stack.
Lo que obtienes con Entorno de pruebas (Sandbox)
- Verificar las estructuras de solicitud y respuesta de la API con la documentación oficial en un entorno seguro.
- Simular motivos específicos de denegación de autorización para validar el manejo de errores y la mensajería al cliente.
- Activar y recibir notificaciones de webhook para actualizaciones de estado como captura, reembolso y disputa.
- Probar los flujos de autenticación 3-D Secure para garantizar el cumplimiento de los requisitos de PSD2 y SCA.
- Validar el manejo de tokens de red y notificaciones de actualización de cuenta sin datos reales.
- Realizar pruebas de carga en la lógica de integración antes de la transición a entornos de producción de mayor volumen.
- Configurar múltiples perfiles de comerciante para probar la conversión de divisas y el procesamiento nacional versus internacional.
- Auditar el registro de ID de transacción, ARN y marcas de tiempo para la conciliación financiera interna.
- Modelar el comportamiento de capturas parciales y múltiples reembolsos en una sola transacción.
- Examinar el impacto de los códigos de categoría de comerciante en las tasas de autorización simuladas y las estructuras de tarifas.
A short scoping call, then a written plan for your MIDs.
Preguntas sobre Entorno de pruebas (Sandbox)
¿Las transacciones de sandbox aparecen en extractos bancarios reales o incurren en tarifas de esquema?
No, las transacciones procesadas dentro de un entorno de pruebas no interactúan con esquemas de pago reales como Visa o Mastercard. Son manejadas por un procesador simulado que emula la respuesta del emisor.
En consecuencia, no se mueven fondos reales, no se cobra a ningún titular de tarjeta y el comerciante no incurre en tarifas de intercambio o de esquema. El entorno está completamente aislado para evitar un impacto financiero.
¿Puedo probar la Autenticación Reforzada de Cliente (SCA) y 3D Secure en el sandbox?
Sí, los entornos de pruebas de alta calidad proporcionan tarjetas de prueba o indicadores específicos para activar los flujos 3DS.
Esto permite a los desarrolladores probar la redirección a un Servidor de Control de Acceso (ACS) simulado y manejar los resultados de autenticación resultantes, como éxito, fallo o omisión.
Es un paso esencial para los comerciantes europeos garantizar el cumplimiento de los mandatos de PSD2 para los pagos electrónicos.
¿Cómo simulo una denegación dura versus una denegación suave en las pruebas?
La simulación generalmente se logra utilizando diferentes números de tarjeta de prueba o montos de transacción especificados en la documentación. Un BIN específico podría asignarse a una respuesta de 'Perdida o Robada' (denegación dura), mientras que otro podría activar 'Fondos Insuficientes' (denegación suave).
Probar estas variantes es vital para que los desarrolladores implementen una lógica de reintento adecuada y distingan entre fallos permanentes y temporales.
¿Los datos de los titulares de tarjetas almacenados en el sandbox están sujetos al cumplimiento de PCI-DSS?
Si bien el sandbox no debe contener datos reales de titulares de tarjetas, la seguridad de las claves API y los datos simulados sigue siendo importante.
La mayoría de los entornos de pruebas utilizan pseudodatos que se asemejan a PAN reales, pero que fallan las comprobaciones del algoritmo de Luhn o pertenecen a rangos no asignados.
Sin embargo, los desarrolladores deben mantener buenas prácticas de seguridad y nunca utilizar datos reales de clientes dentro de un entorno de pruebas para evitar posibles riesgos de fuga de datos.
¿Mis puntos finales de webhook recibirán la misma carga útil que el entorno de producción?
La carga útil JSON o XML entregada a su URL de webhook en el sandbox debe reflejar exactamente el esquema de producción. Esto incluye los mismos campos para el ID de transacción, el monto, la moneda y los códigos de estado.
Probar esto garantiza que su analizador de backend esté configurado correctamente para manejar el flujo de datos en vivo sin necesidad de realizar cambios de código durante la transición a producción.
¿Puedo probar el proceso de liquidación y conciliación en el sandbox?
Puede simular las transiciones que conducen a la liquidación, como mover una transacción de 'autorizada' a 'capturada'. Algunos sandboxes le permiten generar informes simulados que se asemejan a los archivos de liquidación proporcionados por los adquirentes.
Esto ayuda a construir herramientas de conciliación automatizadas que coinciden con los ID de pedido internos con las referencias de transacción proporcionadas por el proveedor de servicios de pago.
Características relacionadas.
¿Listo para la velocidad?
Cuéntanos sobre tu negocio. Te pondremos en contacto con los socios adquirentes y la ruta adecuada, normalmente en una semana.