Tarjetas de prueba de Stripe

Cómo usar una tarjeta de prueba de Stripe

Tres pasos. Las tarjetas de prueba solo funcionan en un entorno de prueba, con claves de API de prueba, así que nada de esta página puede tocar una tarjeta real ni a un cliente real.

1. Cambia a las claves de prueba. Usa tus claves publicable y secreta de prueba, o un entorno de prueba. El Contrato de servicios de Stripe prohíbe hacer pruebas en modo activo con datos de pago reales, y en modo activo una tarjeta de prueba se rechaza con el código testmode_decline.
2. Elige la tarjeta del resultado que quieres ver. La 4242 4242 4242 4242 para un pago correcto sin más. Para probar tu gestión de errores, elige la tarjeta cuya fila lleva el código de rechazo que quieres provocar, con cualquier CVC de tres cifras y cualquier fecha futura.
3. En el código del servidor, usa el PaymentMethod. Stripe recomienda pasar un PaymentMethod como pm_card_visa en vez del número en las llamadas a la API, incluso en pruebas, para que tu código no lleve números de tarjeta y no tengas un problema de PCI al pasar a producción. La columna PaymentMethod trae el de cada tarjeta que lo tiene.

Qué tarjeta provoca qué fallo, y qué verá tu webhook

Gestionar bien un pago fallido exige tener tres cosas en la cabeza a la vez: el error.code que lanza tu llamada a la API, el decline_code que añadió el emisor y el evento que llega después a tu endpoint de webhooks. Stripe documenta cada una en una página distinta, así que casi todas las integraciones se escriben contra una y se llevan una sorpresa con las otras dos. Aquí está lo mismo, con una fila por resultado.

Leerlo como una sola tabla deja dos costumbres. La primera: card_declined no es un motivo, es una categoría. El motivo va en decline_code, y de los ocho rechazos del principio de la tabla solo cinco lo llevan; tarjeta caducada, CVC incorrecto y error de procesamiento se distinguen únicamente por error.code. Si tu gestión de errores decide solo con error.code, unos fondos insuficientes y una tarjeta robada le parecen lo mismo, y le enseñarás el mensaje equivocado al cliente al que simplemente no le llegaba el saldo.

La segunda: hay resultados que nunca aparecen en la respuesta. Un cargo que va a revisión, una disputa que se abre tres semanas después, un reembolso asíncrono que pasa de correcto a fallido: nada de eso se ve en el momento de la llamada. Llega como evento, o no llega, porque nadie construyó el endpoint. Ese es el fallo que merece la pena provocar a propósito: bloquea la tarjeta y mira qué hizo tu sistema con el evento.

Dos notas que no caben en la tabla. Stripe no hace las comprobaciones de CVC ni de código postal si no envías esos campos, así que las tarjetas que simulan que fallan se pagan sin problema si tu formulario no los recoge. Y en los pagos que bloquea Radar, generic_decline es, según la documentación, el código de «Stripe Radar o Adaptive Acceptance han bloqueado el pago». Es deliberado: Stripe pide no dar al cliente más detalle cuando sospecha fraude.

Probar 3D Secure

La normativa de autenticación reforzada de clientes exige 3D Secure en los pagos por internet dentro del Espacio Económico Europeo, y es justo donde más se rompen las integraciones que funcionan, porque el camino feliz nunca pasa por ahí. Un pago que necesita autenticación no falla ni se completa: vuelve con el PaymentIntent en requires_action, y tu front-end tiene que pasarle el control a Stripe.js para que el cliente complete el desafío.

Nueve tarjetas de la tabla recorren las ramas, y la distinción que más tiempo ahorra es obligatorio frente a admitido:

• 4000 0000 0000 3220: la autenticación es obligatoria y se completa. Es la tarjeta contra la que construir. Con ella descubrirás si tu cliente llama de verdad al paso de confirmación o trata requires_action como un error sin decir nada.
• 4000 0000 0000 3055: 3D Secure es admitido pero las reglas predeterminadas no lo piden. Sirve para comprobar que no has hecho obligatoria la autenticación sin querer.
• 4000 0084 0000 1629 y 4000 0084 0000 1280: las dos formas de acabar mal. El cliente autentica y el emisor rechaza igualmente, o falla la propia consulta. Las dos vuelven como card_declined, así que una gestión de errores que da por hecho que un desafío completado es un pago completado enseñará una pantalla de éxito para un pago que no existe.
• 4000 0025 0000 3155 y 4000 0027 6000 3184: las tarjetas guardadas. La primera pide autenticación en los cobros fuera de sesión hasta que la configuras para pagos futuros; la segunda la pide siempre. Si vas a cobrar más adelante sin el cliente delante, estas dos marcan la diferencia entre una renovación que funciona y una que muere.

Un detalle que despista: solo las tarjetas de este grupo prueban de verdad 3D Secure. Otras tarjetas de prueba pueden activarlo, pero Stripe devuelve attempt_acknowledged y se salta los pasos, así que tu interfaz del desafío nunca aparece y concluyes, mal, que funciona. Y los pagos creados directamente en el Dashboard de Stripe no redirigen a 3D Secure: pruébalo desde tu propio front-end o con una llamada a la API.

La tarjeta española, los IBAN SEPA de prueba y Bizum

Stripe mantiene aparte una lista de tarjetas de prueba por país: 64 tarjetas de 58 países, cada una simula un pago correcto con una tarjeta emitida en ese país. Son el último grupo de la tabla, y en esta página la de España va primero, marcada como Tu mercado: 4000 0072 4000 0007, una Visa con el PaymentMethod pm_card_es. Lo que cambia es el país emisor, y para eso sirve: Stripe calcula las comisiones transfronterizas según el país emisor de la tarjeta y avisa de que una tarjeta emitida fuera de EE. UU. puede llevarlas incluso en un entorno de prueba. Lo que no prueba es la autenticación: Stripe indica que las tarjetas de su sección de Europa y Oriente Medio simulan un pago que se completa sin autenticación. La española no te hará pasar por el desafío; para eso está el grupo de 3D Secure.

Para simular dónde está el cliente, y no de dónde es la tarjeta, Stripe documenta los emails con formato de ubicación en Checkout Sessions, Payment Links y tablas de precios: añade +location_ES a la parte local, como en test+location_ES@example.com, y pásalo como customer_email al crear la sesión o como prefilled_email en el enlace de pago. La página de Checkout enseña entonces la divisa y los métodos de pago que vería un cliente en España.

Debajo de la tabla de tarjetas van los valores de prueba de métodos locales, y los primeros son los del adeudo directo SEPA —la domiciliación— con cuentas españolas: seis IBAN, de ES0700120345030000067890 (se cobra) a ES1700120345000002222227 (fondos insuficientes), cada uno con su PaymentMethod pm_sepaDebit_…_es. Stripe publica nueve casos por país; aquí están los seis centrales. No se resuelven como una tarjeta: el pago espera en processing antes de completarse o fallar —en los casos con retraso, al menos tres minutos—, así que cada fila lista la secuencia entera de eventos que recibirá tu webhook. El IBAN de disputa merece una prueba propia: en el adeudo directo SEPA, según la guía de Stripe, el cliente puede disputar un cobro a través de su banco hasta 13 meses después y no hay proceso de apelación.

Bizum no está en la tabla, porque no se prueba con un número que copiar. La guía de Bizum de Stripe lo hace en Checkout con números de teléfono de prueba: el +34600000002 hace que el PaymentIntent pase de requires_action a requires_payment_method con el código payment_method_provider_decline, y cualquier otro número lo lleva a succeeded, en ambos casos unos cinco segundos después de confirmar.

Reembolsos, disputas y lo que llega tarde

En modo activo, los reembolsos son asíncronos: uno puede aparecer como correcto y fallar horas después, o empezar en pending y resolverse luego. Casi ningún conjunto de tests lo cubre, porque con cualquier tarjeta de prueba normal el reembolso se completa al momento y ya no cambia. Dos tarjetas recuperan el comportamiento real: 4000 0000 0000 7726 deja el reembolso pendiente y después lo completa, y 4000 0000 0000 5126 lo da por correcto y después falla. Las dos emiten un evento más tarde, que es justo el camino de código que quieres tener escrito antes de que un cliente te llame por un dinero que nunca le volvió.

Las disputas funcionan igual, a cámara lenta. El cargo se efectúa con normalidad y días después aparece el contracargo, con charge.dispute.created como único aviso. 4000 0000 0000 0259 abre una disputa por fraude, 4000 0000 0000 2685 una por producto no recibido y 4000 0000 0000 1976 una petición de información en lugar de un contracargo completo; conviene separarlas, porque una petición de información a menudo se cierra sin escalar y un contracargo no. 4000 0000 0000 5423 genera en cambio una alerta de fraude preventiva: la red avisándote de que probablemente viene una disputa, cuando aún estás a tiempo de reembolsar por tu cuenta.

Para simular también el desenlace, responde a la disputa con los textos de prueba que Stripe reserva: winning_evidence la cierra a tu favor, losing_evidence la cierra como perdida y escalate_inquiry_evidence convierte una petición de información en un contracargo. Por la API, pásalo como uncategorized_text.

Y el último de los que llegan tarde: 4000 0000 0000 0077 manda los fondos directamente a tu saldo disponible en vez de al pendiente. No es una prueba de pagos, es una prueba de contabilidad: útil si algo aguas abajo concilia las transferencias y no quieres esperar a que pase el periodo de liquidación para saber si funciona.

Descarga las fixtures en JSON o CSV

Una tabla que copias a mano es una tabla que acabarás copiando mal. Los dos botones de descarga te dan las mismas 119 tarjetas en archivos legibles por máquina, generados en el navegador a partir de los datos con los que se pinta esta página: lo que descargas no puede apartarse de lo que acabas de leer.

El JSON es un objeto con source, checked, count y un array cards. Cada tarjeta lleva un id estable que puedes citar en el nombre de un test, los números, la marca, el grupo, una descripción de una línea, las reglas de CVC y caducidad, los cuatro campos del cruce —payment_method, error_code, decline_code y webhook_event— y country, el código ISO del país emisor en las tarjetas del grupo por país. Los campos que no aplican son null, no ausentes, así que tu parser nunca tiene que protegerse de claves que faltan.

El CSV lleva las mismas doce columnas con el entrecomillado de la RFC 4180: se abre en una hoja de cálculo y se carga en pandas sin argumentos de conversión. Los dos archivos van en inglés y en el orden canónico, los descargues desde la página que los descargues. Los valores de métodos locales de debajo de la tabla son para copiar, no para descargar: no van en ninguno de los dos archivos.

Las dos descargas siguen el filtro activo. Reduce la tabla a los rechazos, pulsa Descargar JSON y obtienes diez filas en lugar de las 119, que suele ser lo que quiere un test parametrizado:

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id surfaces $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

Los archivos llevan la URL de la fuente y la fecha de la comprobación, porque una lista de tarjetas sin fecha es una lista en la que no podrás confiar dentro de seis meses. Si Stripe cambia un número, lo honesto es volver a comprobar la fuente, no guardar en tu repositorio una copia caducada.

Lo que de verdad estás construyendo

Nadie busca tarjetas de prueba por gusto. Estás aquí porque estás montando un pago, y el pago es una pieza de algo más grande: un catálogo, un precio que el cliente no puede tocar, una sesión creada en algún sitio con un secreto, un webhook que decide si el pedido cuenta como pagado y todo lo que pasa después de que llega el dinero.

La pieza que más falla no es la tarjeta: es el precio. Una web estática que guarda sus precios en el HTML y envía un importe a un endpoint de pago le está confiando la cifra al navegador, y el navegador no es de fiar. Es una familia entera de errores que las tarjetas de prueba nunca van a detectar, porque un pago manipulado se completa de maravilla.

Clize se apoya en Stripe Checkout justo por eso y pone el precio del lado del servidor: una tienda alojada calcula cada cesta contra el _catalog.json desplegado con la web e ignora el importe que diga el cliente. Si ese es tu problema, el archivo de catálogo tiene aquí un generador y un validador (en inglés), y si solo necesitas que un cliente te pague un importe, clize pay link --amount 49 devuelve una URL de Stripe Checkout real sin cuenta de Stripe propia. Ese cobro es dinero de verdad: mantenlo bien lejos de los números de esta página.

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "factura 1042"