Tarjetas de prueba y sandbox

Cómo probar una pasarela de pago sin tarjetas reales (guía 2026)

Publicado: 2026-09-29  ·  11 min de lectura

Para probar una pasarela de pago sin tarjetas reales se usa el entorno de pruebas (sandbox) de cada proveedor junto con tarjetas de prueba oficiales y números generados válidos por el algoritmo de Luhn.

Puntos clave

• Nunca uses tarjetas reales en pruebas: expones datos, arriesgas cargos reales y puedes incumplir PCI DSS.
• Trabaja siempre en el sandbox con claves de API de prueba.
• Cubre 4 tipos de prueba: éxito, rechazos, 3D Secure y reembolsos/contracargos.
• Distingue las tarjetas oficiales (para el flujo de la pasarela) del generador Luhn (para validación, volumen y formatos).
• Separa las pruebas de formato de las de flujo para que sean deterministas.
• Usa un checklist de QA y automatiza los escenarios críticos.

Este es el flujo estándar que siguen los equipos de QA en 2026: separar las pruebas de validación de formato de las pruebas de flujo de pago, cubrir todos los escenarios de error y nunca tocar una tarjeta de producción. En esta guía verás por qué, cómo hacerlo paso a paso y qué errores evitar.

Por qué no usar tarjetas reales en pruebas

La tentación de probar con una tarjeta real "solo una vez" es un error caro. Estos son los motivos para evitarlo:

• Riesgo de cargos reales. Un descuido en las claves de producción puede generar cobros de verdad.
• Exposición de datos. Introducir un número real en un entorno de desarrollo lo deja al alcance de logs, bases de datos y backups.
• Incumplimiento de PCI DSS. Manejar datos de tarjeta reales amplía el alcance de la norma y sus auditorías.
• Resultados no reproducibles. No puedes forzar un rechazo concreto con una tarjeta real, así que no puedes probar los caminos de error.
• Problemas legales y con el emisor. Usar tu propia tarjeta en pruebas repetidas puede disparar alertas antifraude.

La alternativa es sencilla y gratuita: sandbox + tarjetas de prueba. Todo lo que necesitas para validar una integración está disponible sin usar datos reales.

Qué es el sandbox y cómo funciona

El sandbox es un entorno aislado que replica el comportamiento de la pasarela sin conectar con el sistema financiero real. Tiene sus propias credenciales y sus propios datos.

Puntos clave:

• Claves de API de prueba. Stripe usa claves sk_test_ y pk_test_; PayPal usa el sandbox con su propio client_id. Estas claves dirigen el tráfico al entorno de pruebas.
• Endpoints distintos. El sandbox apunta a servidores de prueba (por ejemplo, api-m.sandbox.paypal.com), no a los de producción.
• Datos independientes. Los clientes, tarjetas y transacciones del sandbox no afectan a tu cuenta real.
• Comportamiento simulado. Puedes forzar aprobaciones, rechazos y autenticaciones con tarjetas de prueba.

Configurar el sandbox correctamente es el primer paso. Si mezclas claves de prueba con endpoints de producción (o al revés), las pruebas no serán fiables.

Los 4 tipos de prueba que debes cubrir

Una integración de pagos sólida no se conforma con que "el pago de éxito funcione". Hay cuatro bloques de escenarios que conviene cubrir:

1. Pago exitoso

El caso base: la tarjeta se aprueba y la orden se completa. Verifica que:

• El estado de la transacción es COMPLETED o succeeded.
• Se registra el pago correctamente en tu sistema.
• El importe y la moneda coinciden con lo esperado.
• El usuario recibe la confirmación adecuada.

2. Rechazos y errores

Aquí está la mayor parte del valor de las pruebas. Debes reproducir cada código de error relevante:

• Fondos insuficientes (insufficient_funds).
• Tarjeta rechazada (card_declined).
• Tarjeta vencida (expired_card).
• CVC incorrecto (incorrect_cvc).
• Número incorrecto (incorrect_number).
• Errores de validación del propio formulario.

Para cada uno, comprueba que tu aplicación muestra un mensaje claro y no rompe el flujo.

3. Autenticación 3D Secure

Si tu integración usa 3DS, prueba tanto el camino de autenticación exitosa como el de autenticación fallida. Verifica que el redireccionamiento funciona, que los timeouts se gestionan y que un rechazo tras autenticar se trata correctamente.

4. Reembolsos y contracargos

El ciclo de vida de un pago no termina en el cobro. Prueba:

• Reembolso total y parcial. Comprueba el estado (pending, succeeded, failed) y los webhooks asociados.
• Reembolso asíncrono. Algunas pasarelas procesan el reembolso con retraso; asegúrate de gestionar ese estado.
• Contracargos (disputas). Muchas pasarelas permiten simular disputas para probar tu flujo de gestión.

Cubrir estos cuatro bloques te da la seguridad de que tu integración responde bien en cualquier escenario, no solo en el feliz.

Tarjetas oficiales vs generador Luhn: cuándo usar cada una

Ambas herramientas son necesarias, pero para cosas distintas. Confundirlas es uno de los errores más frecuentes.

La regla práctica: usa las tarjetas oficiales para probar el comportamiento de la pasarela y el generador Luhn para validación, volumen y datos de prueba genéricos. Tienes la lista oficial de tarjetas de prueba de Stripe y PayPal en nuestra guía dedicada y más números en el directorio de tarjetas de prueba.

Paso a paso: probar tu pasarela con el generador

Este es un flujo práctico para preparar tus pruebas:

1. Configura el sandbox. Obtén tus claves de API de prueba y apunta tu integración a los endpoints de sandbox.
2. Define los escenarios. Haz una lista de los casos que vas a cubrir: éxito, cada rechazo, 3DS y reembolsos.
3. Genera tus datos de prueba. Abre el generador de tarjetas de crédito, elige la red, el formato de salida y la cantidad (hasta 9999). Descarga el lote en JSON, CSV o XML.
4. Valida los números. Comprueba cada número con el validador de tarjetas para asegurarte de que pasa Luhn y que el tipo y el BIN son los esperados.
5. Carga los datos en tus fixtures. Alimenta tus pruebas automatizadas con los números generados.
6. Ejecuta los escenarios de flujo. Para los rechazos y el 3DS, usa las tarjetas oficiales de la pasarela (las que reproducen cada código de decline).
7. Verifica los resultados. Comprueba estados, mensajes de error, webhooks y registros.
8. Documenta y automatiza. Convierte los casos críticos en pruebas automatizadas que se ejecuten en cada despliegue.

Si quieres elegir una red concreta para tus datos de prueba, puedes empezar por la página de selección de tarjetas de crédito.

Un caso real de QA

Daniel, ingeniero de QA en una plataforma de suscripciones, tenía un problema recurrente: cada vez que Stripe cambiaba un mensaje de error, sus pruebas fallaban. La causa era que sus tests dependían de las tarjetas oficiales para todo, incluidas las pruebas de validación del formulario. Al separar las pruebas, la situación mejoró: las de formato usaban números generados por Luhn (estables y sin dependencia externa) y las de flujo seguían usando las tarjetas oficiales. El resultado fue una suite más rápida y mucho menos frágil, que ya no se rompía con cada cambio del proveedor.

Checklist de QA para pruebas de pago

Antes de dar por buena una integración, repasa esta lista:

• La integración usa claves de API de prueba y endpoints de sandbox.
• El pago de éxito completa la orden y actualiza el estado correctamente.
• Cada código de decline relevante está probado y muestra un mensaje claro.
• El flujo 3D Secure funciona en el camino de éxito y en el de fallo.
• Los reembolsos (total, parcial y asíncrono) se gestionan bien.
• Los webhooks se reciben y se procesan correctamente.
• Los logs no contienen datos sensibles (número completo, CVV).
• Los datos de prueba son válidos por Luhn y están versionados como fixtures.
• Los escenarios críticos están automatizados.
• Existe una separación clara entre pruebas de formato y de flujo.

Marcar esta lista reduce drásticamente los incidentes en producción.

Errores comunes al probar pagos

Estos son los fallos que más se repiten en los equipos:

• Mezclar claves de prueba y producción. El error más peligroso: puede provocar cargos reales.
• Usar tarjetas reales "solo para ver". Riesgo innecesario y potencial incumplimiento de PCI DSS.
• Reutilizar la misma tarjeta en varios escenarios. Algunas pasarelas mantienen el estado de la tarjeta entre pruebas, así que los resultados dejan de ser fiables.
• Olvidar el CVC. Si no lo envías, la comprobación de CVC se omite y no puedes probar ese fallo.
• No probar los caminos de error. Un pago de éxito no valida la integración; los rechazos sí.
• Ignorar los webhooks. Muchos estados se actualizan de forma asíncrona; si no pruebas los webhooks, no verás esos cambios.
• No limpiar los datos de prueba. Datos sucios entre ejecuciones producen falsos positivos.

Evitar estos errores te ahorrará tiempo y, sobre todo, sorpresas en producción.

¿Vas a empezar tus pruebas ahora? Prepara tus datos con el generador de tarjetas de crédito y verifica cada número con el validador antes de integrarlos en tus fixtures.

Conclusión

Probar una pasarela de pago sin tarjetas reales es más seguro, más reproducible y más completo que hacerlo con datos reales. La fórmula es clara: sandbox + claves de prueba + tarjetas oficiales + generador Luhn, con una separación limpia entre pruebas de formato y de flujo.

Cubre los cuatro bloques (éxito, rechazos, 3DS y reembolsos), sigue el checklist y evita los errores clásicos. Con esa disciplina, tu integración de pagos aguantará los casos límite que en producción siempre aparecen.

Empieza generando tus datos de prueba en el generador de tarjetas de crédito y valídalos en el validador. Si quieres la lista oficial de números, consulta nuestra guía de tarjetas de prueba de Stripe y PayPal.

Aviso de uso responsable: los números generados en este sitio son ficticios y válidos únicamente por el algoritmo de Luhn. No corresponden a tarjetas reales, no sirven para comprar y deben usarse solo para pruebas de software. Usarlos para fraude es ilegal.

Fuentes y lecturas relacionadas

• Stripe, "Test card numbers" (documentación oficial): docs.stripe.com/testing
• PayPal Developer, "Card testing" (sandbox): developer.paypal.com
• Tarjetas de prueba de Stripe y PayPal: números oficiales
• Qué es el CVV o CVC de una tarjeta

Preguntas Frecuentes

¿Puedo probar pagos sin una tarjeta de prueba oficial?

Para probar la validación de formato, sí: cualquier número válido por Luhn sirve. Para probar el flujo de la pasarela y sus rechazos, necesitas las tarjetas oficiales.

¿El sandbox se comporta igual que producción?

No del todo. El sandbox simula el comportamiento, pero no replica todas las reglas antifraude del emisor. Úsalo para validar tu integración, no para predecir el 100% del comportamiento real.

¿Cuántas tarjetas de prueba necesito?

Una por escenario. Como el estado de la tarjeta puede persistir entre pruebas, conviene usar números distintos para casos independientes.

¿Es legal generar números de tarjeta para pruebas?

Generar números ficticios válidos por Luhn para probar software es legal. Usarlos para fraude o suplantación no lo es, y además no funcionarían, porque no corresponden a tarjetas reales.

testingsandboxwebhooksQA