Entorno de pruebas (Sandbox)
El entorno de pruebas de Cardflo permite a los desarrolladores integrar y probar soluciones de pago sin afectar las transacciones en vivo.
Este espacio aislado refleja nuestro entorno de producción, permitiendo pruebas exhaustivas de todas las funciones de Cardflo, desde el procesamiento de pagos hasta los webhooks y las interacciones con la API, asegurando una transición fluida a las operaciones en vivo.
- Categoría
- Desarrollador
- Capacidades
- 10
- Disponible en
- Todos los planes
La visión general
A sandbox environment acts as a non-production instance of a payment gateway or orchestration platform, allowing developers to model the entire transaction lifecycle without moving real funds. It operates as a replica of the live API, including components for authorisation, capture, and settlement.
Within this isolated container, technical teams can verify their integration logic, request structures, and authentication headers against strict validation rules.
By using test credentials and simulated Card Identification Numbers (BINs), merchants can evaluate how their backend reacts to various responses, such as successful payments, soft declines, or 3DS authentication prompts.
The sandbox sits between the merchant application and the simulated acquirer, providing a safe space to ensure that the code handles edge cases, such as insufficient funds or expired cards,
before moving to a live production environment where errors could result in loss of revenue or increased chargeback ratios.
Cómo funciona
Credential generation and authentication
Developers obtain a specific set of API keys or Bearer tokens designated for the testing environment. These credentials route requests to a mock processor rather than the live payment schemes.
This ensures that no merchant identification number (MID) is billed for processing fees and no real cardholder data enters the production systems.
Simulated transaction processing
The merchant sends a payment request using predefined test card numbers that trigger specific outcomes. For example, using one BIN might simulate a successful authorisation, while another triggers a CVV mismatch or a hard decline.
The sandbox returns an identical JSON response structure to the live API to ensure compatibility.
Webhook event notification
Once a transaction status changes in the sandbox, the system generates asynchronous webhooks. The merchant server receives these notifications at a designated endpoint to verify that their system correctly updates the internal database.
This step is critical for testing automatic order fulfilment or subscription management logic in real time.
State change and settlement
Users can manually or programmatically transition the state of a transaction from authorised to settled or refunded within the testing dashboard.
This allows for the verification of post-purchase workflows, including the handling of retrieval requests or partial refunds, ensuring the merchant UI reflects the correct financial state.
Por qué importa
Risk mitigation during deployment
Implementing new payment flows directly in production creates high operational risk. By utilising a sandbox, developers can identify logical errors or malformed API requests that would otherwise lead to failed checkouts.
This isolation protects the integrity of the live Merchant Identification Number and prevents accidental triggers of anti-fraud filters that could occur during aggressive testing of new card-present or card-not-present integration logic.
Validation of complex logic
Modern payments often involve multi-step processes like Strong Customer Authentication (SCA) or recurring billing. A sandbox allows for the rigorous testing of cardholder-initiated and merchant-initiated transactions without the financial cost of real transactions.
It ensures that the system correctly interprets various decline codes and response messages from issuers, allowing for the refinement of dunning logic and retry strategies to optimise eventual conversion rates.
Casos de uso
Initial API integration
New merchants use the sandbox to map their internal order management systems to the payment gateway's API endpoints. This confirm that data fields like currency codes and merchant category codes are correctly formatted for authorisation.
Recurring billing verification
Subscription-based businesses test their dunning sequences by simulating card expiry or insufficient funds. This ensures that the system correctly attempts retries and sends appropriate notifications to the customer before service suspension.
Webhook endpoint debugging
Developers use the testing environment to verify that their firewall and server configurations allow for incoming webhook notifications. This prevents issues where orders remain 'pending' despite successful authorisation at the acquirer level.
Alternative payment method testing
Before enabling local payment methods, merchants can simulate the redirect flows required for APMs. This ensures that the user experience remains consistent when the customer is sent to a third-party wallet or bank portal.
En cifras
Typical efficiency gains observed by technical teams when using a comprehensive sandbox compared to manual documentation review and direct production testing.
Estimated range of reduction in post-deployment bugs related to payment logic when rigorous sandbox testing is implemented as part of the CI/CD pipeline.
Industry standard response time for mock API endpoints, allowing for rapid iteration during the software development lifecycle.
Términos relacionados
Talk to our team about a live rollout on your acquiring stack.
Lo que obtienes con Entorno de pruebas (Sandbox)
- Simule el ciclo de vida completo del pago, incluidas las aprobaciones y los rechazos
- Pruebe la integración con la API y los SDK de Cardflo
- Experimente con diferentes métodos y configuraciones de pago
- Valide las notificaciones y respuestas de los webhooks
- Desarrolle y depure flujos de pago personalizados de forma segura
- Acceda a datos de prueba completos para varios escenarios
- Configure multiple merchant profiles to test currency conversion and domestic versus international processing.
- Audit the logging of transaction IDs, ARNs, and timestamps for internal financial reconciliation.
- Model the behaviour of partial captures and multiple refunds on a single transaction.
- Examine the impact of merchant category codes on simulated authorisation rates and fee structures.
A short scoping call, then a written plan for your MIDs.
Preguntas sobre Entorno de pruebas (Sandbox)
¿Cuál es el propósito del entorno de pruebas de Cardflo?
El entorno de pruebas (sandbox) proporciona un espacio seguro y aislado para que los desarrolladores integren y prueben la plataforma de orquestación de pagos de Cardflo.
Permite realizar pruebas exhaustivas de todas las funciones sin afectar las cuentas de comerciantes en vivo o las transacciones de clientes, asegurando una integración robusta.
¿El entorno de pruebas es compatible con todas las funciones de Cardflo?
Sí, el entorno de pruebas de Cardflo está diseñado para reflejar el entorno de producción lo más fielmente posible.
Los desarrolladores pueden probar el procesamiento central de pagos, la lógica de enrutamiento inteligente, los mecanismos de recuperación de rechazos y las interacciones de la API, asegurando una paridad de funciones completa para el desarrollo de la integración.
¿Cómo accedo al entorno de pruebas de Cardflo?
El acceso al entorno de pruebas de Cardflo se proporciona al crear la cuenta. Los desarrolladores reciben las credenciales y la documentación necesarias para comenzar a probar de inmediato.
Hay guías completas disponibles para ayudar con la configuración inicial y varios escenarios de prueba, facilitando un desarrollo eficiente.
Is stored cardholder data in the sandbox subject to PCI-DSS compliance?
While the sandbox should not contain real cardholder data, the security of the API keys and the simulated data remains important. Most sandbox environments use pseudo-data that resembles real PANs but fails Luhn algorithm checks or belongs to unassigned ranges.
However, developers should maintain good security practices and never use real customer data within a testing environment to avoid potential data leakage risks.
Will my webhook endpoints receive the same payload as the production environment?
The JSON or XML payload delivered to your webhook URL in the sandbox should mirror the production schema exactly. This includes the same fields for transaction ID, amount, currency, and status codes.
Testing this ensures that your backend parser is correctly configured to handle the live data stream without needing to make code changes during the transition to production.
Can I test the settlement and reconciliation process in the sandbox?
You can simulate the transitions that lead to settlement, such as moving a transaction from 'authorised' to 'captured'. Some sandboxes allow you to generate mock reports that resemble the settlement files provided by acquirers.
This helps in building automated reconciliation tools that match internal order IDs with the transaction references provided by the payment service provider.
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.