Las tarjetas de prueba de Stripe son un catálogo corto de números que solo el entorno de pruebas de esa pasarela reconoce. No se pueden usar para cobrar y no funcionan en la pasarela de otro proveedor, pero son la forma estándar de comprobar que una integración de pago está bien montada antes de tocarla con dinero. Esta guía explica de dónde salen, qué demuestra cada tipo y qué conviene no copiar nunca de un tutorial antiguo.
¿Por qué cada pasarela publica sus propias tarjetas?
Una pasarela no se puede probar con tarjetas reales: usarías una credencial de pago auténtica contra un sistema que quizá no está auditado como producción, y cualquier envío accidental se convertiría en una transacción de verdad. La alternativa es que el propio proveedor publique un puñado de números que su simulador reconoce.
Cuando pagas en modo de pruebas, la respuesta no la genera el emisor de la tarjeta. La genera el simulador de la pasarela, que ha sido programado para reaccionar de una forma concreta ante ciertos números. Ese simulador es específico de cada proveedor: los valores que provocan un rechazo en un servicio no significan nada en otro, y las fechas aceptadas tampoco tienen por qué coincidir.
De ahí una consecuencia que conviene interiorizar: una tarjeta de prueba no es un dato del mundo de los pagos, es una entrada de un programa concreto. Copiarla de la documentación de otra pasarela suele acabar en un error de tarjeta no reconocida y en media tarde perdida.
La tarjeta de éxito genérica y qué demuestra
Stripe documenta una tarjeta genérica de éxito que se construye repitiendo el mismo bloque de cuatro dígitos hasta completar los dieciséis, empezando por el cuatro que corresponde a Visa. Acepta cualquier fecha de vencimiento futura y cualquier código de seguridad de tres dígitos.
Leída con su contrato completo, esa tarjeta sirve en el modo de pruebas de la pasarela y en ningún otro sitio. Enviarla a un sistema en modo real no es una prueba, es un intento de transacción, y el número no pertenece a ninguna cuenta.
¿Qué demuestra cuando la usas en el entorno correcto? Que el flujo completo está montado: que el formulario recoge los datos, que el servidor crea el cargo contra la dirección correcta y con la clave correcta, que la respuesta se interpreta bien y que la interfaz muestra la confirmación. Es un buen primer paso y nada más.
Lo que no demuestra es igual de importante. No dice nada sobre el tratamiento de un rechazo, no ejercita la autenticación reforzada y no comprueba que el sistema sepa devolver dinero. Para eso hacen falta los otros tipos del catálogo.
Tarjetas que siempre se rechazan
El catálogo incluye números que producen siempre un rechazo, y lo hacen con un motivo concreto: fondos insuficientes, tarjeta perdida, tarjeta caducada, operación no permitida y otros códigos con nombre propio. Se llaman así porque el simulador devuelve exactamente ese código, y su utilidad está en comprobar que la aplicación lo traduce a un mensaje que una persona pueda entender.
Al probarlas conviene fijarse en tres cosas. La primera es el texto que ve el cliente: fondos insuficientes se puede explicar, y un código de error en bruto no. La segunda es qué ocurre con el pedido, porque un rechazo no debe dejar el carrito vacío ni el inventario reservado. La tercera es si el sistema reintenta el cobro por su cuenta, porque reintentar un rechazo definitivo genera duplicados y alertas antifraude.
Ojo con la tentación de probar los rechazos contra el sistema en producción. Igual que la tarjeta genérica, estos números solo tienen sentido en el entorno de pruebas; contra un sistema real no obtendrás el rechazo educado que buscas, sino un intento de cargo.
Probar 3-D Secure y sus cuatro finales
La autenticación reforzada del titular añade un paso al pago: el banco abre una pantalla propia y la persona confirma la operación, normalmente desde su aplicación móvil. Es el punto donde más flujos se rompen, porque interviene un tercero y el usuario puede desaparecer en mitad del proceso.
El proveedor documenta tarjetas de prueba para cada desenlace. Los cuatro que merecen una prueba automatizada son:
- La autenticación se supera sin intervención del cliente.
- La autenticación se exige y el cliente la completa.
- El cliente rechaza la autenticación.
- El cliente abandona la pantalla a medias.
El cuarto es el que casi nadie cubre y el que más incidencias produce. La prueba interesante no es la ida, sino la vuelta: comprueba que al regresar la aplicación reconstruye el estado correcto, que el pedido no queda bloqueado para siempre y que se puede reintentar sin crear un segundo cargo.
¿Dónde está la lista actualizada?
La lista completa vive en la documentación de la propia pasarela, en su sección de pruebas. No la reproduzcas de memoria ni la pegues en la wiki interna: los catálogos cambian cuando el proveedor añade casos nuevos, y una copia desactualizada es peor que un enlace a la fuente. Añade siempre una nota con la fecha en que consultaste la lista.
La regla de trabajo es sencilla. Para una prueba puntual, consulta la documentación en el momento. Para una batería que se ejecuta a diario, guarda los valores junto al caso que cubren, con su fecha de revisión. Y no mezcles tarjetas de dos pasarelas en el mismo archivo de datos de prueba: aunque se parezcan, responden a simuladores distintos.
Cuando lo que necesitas es material propio para la parte de formato y validación, el generador de este sitio produce lotes con prefijos de cada marca. Son datos estructuralmente correctos y nunca emitidos: sirven para comprobar tu formulario y tu validador, no para provocar respuestas de una pasarela.
Para quien programa
La diferencia entre una batería útil y una que solo repite el caso feliz está en cómo se organizan los escenarios. Estas son las precauciones que más veces aparecen en una integración real.
- Un caso por desenlace. No basta con probar el éxito; cada código de rechazo que tu interfaz traduce debería tener su prueba, y cada prueba su valor documentado.
- Entorno fijado en la configuración. La dirección del servicio y la clave deben venir de la configuración y no del código, para que no exista la posibilidad de apuntar a producción por descuido.
- Escenarios de autenticación incluidos. Los cuatro finales de la autenticación reforzada deberían estar automatizados; el abandono es el que más veces se olvida.
- Sin duplicados. Después de cada prueba, compara el número de operaciones creadas con el número de pedidos. Un reintento mal puesto se ve ahí y en ningún otro sitio.
- Datos de prueba etiquetados. Nombra los archivos y las constantes de forma que quede claro que son valores falsos, y revisa que no viajen a un entorno con datos reales.
Un último detalle de higiene: los valores de prueba de una pasarela no deberían aparecer en un sistema que procese cobros de verdad. La separación entre entornos es más eficaz que cualquier comprobación escrita en el código.
Siguientes pasos
Si vas a montar la batería completa, empieza por la lista de comprobación del formulario de pago, que cubre rechazos, reintentos y devoluciones. Para elegir con criterio qué marca usar en cada caso, consulta las tarjetas de prueba por marca. Y si en tu organización los entornos de prueba se auditan, revisa antes las notas sobre datos de prueba y cumplimiento.