Cada vez que trabajes con una tarjeta de prueba, usa las claves de prueba de la API en todas las llamadas a la API, tanto si ofreces un formulario de pago para probar de forma interactiva o para escribir código de prueba.
Error habitual
No uses datos de tarjetas reales. El Contrato de servicios de Stripe prohíbe las pruebas en modo directo con datos reales de los métodos de pago. Usa tus claves de API de prueba y los números de tarjeta que aparecen a continuación.
Pruebas interactivas
Cuando realices pruebas interactivas, usa un número de tarjeta, como 4242 4242 4242. Introduce el número de la tarjeta en el Dashboard o en cualquier forma de pago.
Usa una fecha futura válida, como 12/34
Usa cualquier CVC de tres dígitos (cuatro dígitos si usas una tarjeta American Express).
Usa cualquier valor para los demás campos del formulario.
Cómo probar un formulario de forma interactiva con el número de tarjeta de prueba 4242 4242 4242 4242
Código de prueba
Cuando escribas el código de prueba, utiliza un PaymentMethod como pm_card_visa en lugar de un número de tarjeta. No recomendamos usar números de tarjeta directamente en llamadas API o código del lado del servidor, incluso en modo de prueba. Si los usas, es posible que tu código no cumpla con la normativa PCI cuando pases a modo activo. De forma predeterminada, no se adjunta un PaymentMethod a un Cliente.
La mayoría de las integraciones ya no usan tokens, pero hacemos que los tokens de prueba como tok_visa estén disponibles si los necesitas.
Cuando esté todo listo para pasar la integración al modo activo, reemplaza tus claves de API secretas y publicables de prueba por las claves activas. No puedes procesar pagos reales si tu integración sigue usando las claves de prueba de la API.
Tarjetas por marca
Para simular un pago realizado con éxito para una marca de tarjeta específica, utiliza las tarjetas de prueba de la siguiente lista.
Precaución
Las comisiones transfronterizas se calculan en función del país del emisor de la tarjeta. Las tarjetas cuyo país emisor no es EE. UU. (como JCB y UnionPay) pueden estar sujetas a una comisión transfronteriza, incluso en modo de prueba.
Marca
Número
CVC
Fecha
Visa
3 dígitos aleatorios
Cualquier fecha futura
Visa (débito)
3 dígitos aleatorios
Cualquier fecha futura
Mastercard
3 dígitos aleatorios
Cualquier fecha futura
Mastercard (serie 2)
3 dígitos aleatorios
Cualquier fecha futura
Mastercard (débito)
3 dígitos aleatorios
Cualquier fecha futura
Mastercard (prepago)
3 dígitos aleatorios
Cualquier fecha futura
American Express
4 dígitos aleatorios
Cualquier fecha futura
American Express
4 dígitos aleatorios
Cualquier fecha futura
Discover
3 dígitos aleatorios
Cualquier fecha futura
Discover
3 dígitos aleatorios
Cualquier fecha futura
Discover (débito)
3 dígitos aleatorios
Cualquier fecha futura
Diners Club
3 dígitos aleatorios
Cualquier fecha futura
Diners Club (tarjeta de 14 dígitos)
3 dígitos aleatorios
Cualquier fecha futura
BCcard y DinaCard
3 dígitos aleatorios
Cualquier fecha futura
JCB
3 dígitos aleatorios
Cualquier fecha futura
UnionPay
3 dígitos aleatorios
Cualquier fecha futura
UnionPay (débito)
3 dígitos aleatorios
Cualquier fecha futura
UnionPay (tarjeta de 19 dígitos)
3 dígitos aleatorios
Cualquier fecha futura
La mayoría de las tarjetas Cartes Bancaires y eftpos son de marca compartida con Visa o Mastercard. Las tarjetas de prueba en la siguiente tabla simulan pagos exitosos con tarjetas de marca compartida.
Marca/marca compartida
Número
CVC
Fecha
Cartes Bancaires/Visa
3 dígitos aleatorios
Cualquier fecha futura
Cartes Bancaires/Mastercard
3 dígitos aleatorios
Cualquier fecha futura
eftpos Australia/Visa
3 dígitos aleatorios
Cualquier fecha futura
eftpos Australia/Mastercard
3 dígitos aleatorios
Cualquier fecha futura
Tarjetas por país
Para simular pagos efectuados correctamente desde países específicos, utiliza tarjetas de prueba de las siguientes secciones.
Para probar las suscripciones que requieren mandatos y notificaciones previas al débito, consulta pagos recurrentes de India.
Australia (AU)
Visa
China (CN)
Visa
Hong Kong (HK)
Visa
India (IN)
Visa
Japón (JP)
Visa
Japón (JP)
JCB
Malasia (MY)
Visa
Nueva Zelanda (NZ)
Visa
Singapur (SG)
Visa
Taiwán (TW)
Visa
Tailandia (TH)
Visa (crédito)
Tailandia (TH)
Visa (débito)
Pagos rechazados
Para poner a prueba la lógica de gestión de errores de tu integración simulando pagos que el emisor rechaza por varios motivos, utiliza las tarjetas de prueba de esta sección. El uso de una de estas tarjetas da como resultado un error de tarjeta con el código de error y el código de rechazo dados.
Error habitual
Para simular un CVC incorrecto, debes utilizar cualquier número de tres dígitos. Si no proporcionas un CVC, Stripe no realizará la verificación del CVC, por lo que no se podrán producir errores en la verificación.
Las tarjetas de la tabla anterior no pueden adjuntarse a un objeto Customer. Para simular un pago rechazado con una tarjeta vinculada correctamente, usa la siguiente opción.
Descripción
Número
Detalles
Rechazo después de adjuntar
Esta tarjeta se adjunta correctamente a un objeto Customer, pero fallan los intentos de cobrarle al cliente.
Prevención de fraude
Radar, el sistema de prevención de fraude de Stripe, puede bloquear pagos cuando estos presenten un nivel elevado de riesgo o fallen las comprobaciones de verificación. Puedes usar las tarjetas de esta sección para probar tu configuración de Radar. También puedes utilizarlas para probar cómo responde tu integración a los pagos bloqueados.
Cada tarjeta simula factores de riesgo específicos. Tu configuración de Radar determina qué factores de riesgo hacen que se bloquee un pago. Los pagos bloqueados dan lugar a errores de tarjeta con un código de error de fraude.
Error habitual
Para simular un error en la verificación del CVC, debes proporcionar un CVC utilizando cualquier número de tres dígitos. Para simular un error en la verificación del código postal, debes proporcionar cualquier código postal válido. Si no proporcionas esos valores, Radar no realizará las comprobaciones correspondientes, por lo que no se podrán producir errores en ellas.
Para probar errores derivados de información no válida, debes aportar datos que no sean válidos. No necesitas ninguna tarjeta de prueba especial; cualquier valor no válido funcionará. Por ejemplo:
Para simular una transacción disputada, usa las tarjetas de prueba de esta sección. Luego, para simular que has perdido la disputa o que se ha resuelto a tu favor, aporta la prueba correspondiente.
Descripción
Número
Detalles
Fraudulento
Con la configuración de cuenta predeterminada, el cargo se realiza correctamente, pero se disputa como fraudulento. Este tipo de disputa está protegida después de la autenticación mediante 3D Secure.
No recibido
Con la configuración de cuenta predeterminada, el cargo se efectúa correctamente, pero se disputa como producto no recibido. Este tipo de disputa no está protegido después de la autenticación mediante 3D Secure.
Investigación
Con la configuración de cuenta predeterminada, el cargo se realiza correctamente, pero se disputa como una petición de información.
La disputa se cierra y marca como ganada. El importe del cargo y las comisiones relacionadas se acreditan en tu cuenta.
losing_evidence
La disputa está cerrada y marcada como perdida. No se acreditan fondos en tu cuenta.
Reembolsos
En modo activo, los reembolsos son asíncronos. Un reembolso puede aparecer como correcto y después fallar, o aparecer como pending al principio y luego como correcto. Para simular reembolsos con estos comportamientos, usa las tarjetas de prueba de esta sección. (Con las demás tarjetas, los reembolsos se efectúan correctamente de inmediato y no cambian de estado).
Descripción
Número
Detalles
Pago asíncrono efectuado correctamente
El cargo se efectúa correctamente. Si emites un reembolso, el estado inicial será pending. Después de un tiempo, el estado pasa a succeeded y envía un evento de webhookcharge.refund.updated.
Error asíncrono
El cargo se efectúa correctamente. Si emites un reembolso, el estado inicial será succeeded. Después de un tiempo, el estado pasa a failed y envía un evento de webhookcharge.refund.updated.
Solo puedes cancelar un reembolso con tarjeta desde el Dashboard. En el modo activo, puedes cancelar un reembolso de tarjeta en un periodo de tiempo corto pero no específico. modo de prueba simula ese período al permitirte cancelar un reembolso de tarjeta en 30 minutos.
Saldo disponible
Para enviar los fondos desde una transacción de prueba directamente al saldo disponible, usa las tarjetas de prueba de esta sección. Las demás tarjetas de prueba envían los fondos de los pagos correctos a tu saldo pendiente.
Descripción
Número
Detalles
Omitir saldo pendiente
El cargo de EE. UU. se efectúa correctamente. Los fondos se añaden directamente a tu saldo disponible, omitiendo tu saldo pendiente.
Omitir saldo pendiente
El cargo internacional se efectúa correctamente. Los fondos se añaden directamente a tu saldo disponible, omitiendo tu saldo pendiente.
Autenticación mediante 3D Secure
La autenticación mediante 3D Secure requiere un nivel de autenticación adicional en las transacciones con tarjeta de crédito. Las tarjetas de prueba de esta sección te permiten simular la activación de la autenticación en diferentes flujos de pago.
Solo las tarjetas de esta sección prueban de manera eficaz tu integración con 3D Secure simulando un comportamiento 3DS definido, como un flujo de comprobación o una tarjeta no aceptada. Otras tarjetas de prueba de Stripe pueden activar 3DS, pero devolvemos attempt_acknowledged para omitir los pasos adicionales, ya que las pruebas de 3DS no son el objetivo de esas tarjetas.
El Dashboard no es compatible
3D Secure no redireccionará los pagos creados directamente en el Dashboard de Stripe. En su lugar, usa el front-end de tu propia integración o haz una llamada a la API.
Autenticación y configuración
Para simular flujos de pago que incluyan autenticación, utiliza las tarjetas de prueba de esta sección. Algunas de estas tarjetas también pueden configurarse para pagos futuros o ya lo han sido.
Descripción
Número
Detalles
Autenticar a no ser que esté configurada
Esta tarjeta requiere la autenticación para los pagos fuera de sesión, a menos que la configures para pagos futuros. Después de configurarla, los pagos fuera de sesión ya no requieren autenticación. Sin embargo, los pagos en sesión con esta tarjeta siempre requieren autenticación.
Autenticar siempre
Esta tarjeta exige autenticación en todas las transacciones, independientemente de cómo la hayas configurado.
Ya está configurada
Esta tarjeta ya está configurada para su uso fuera de la sesión. Requiere autenticación para pagos únicos y otros pagos durante la sesión. Sin embargo, todos los pagos fuera de la sesión se hacen efectivos como si la tarjeta se hubiera configurado previamente.
Fondos insuficientes
Esta tarjeta requiere autenticación para pagos puntuales. Se rechazan todos los pagos con un código de error insufficient_funds incluso después de que se haya autenticado con éxito o de que se haya configurado previamente.
Soporte y disponibilidad
Stripe solicita la autenticación cuando lo requiere la normativa o cuando se activa debido a tus reglas de Radar o a un código personalizado. Es posible que, aunque se solicite la autenticación, no pueda realizarse. Esto sucede, por ejemplo, si la tarjeta del cliente no está inscrita o si hay un error. Usa las tarjetas de prueba de esta sección para simular varias combinaciones de estos factores.
Para que el pago se efectúe correctamente, debe completarse la autenticación mediante 3D Secure. Las reglas de Radar solicitan la autenticación mediante 3D Secure para esta tarjeta de forma predeterminada.
Se requiere 3DS
Rechazada
La autenticación mediante 3D Secure es obligatoria, pero los pagos se rechazan con un código de error card_declined después de la autenticación. De forma predeterminada, las reglas de Radar te solicitarán la autenticación mediante 3DS para esta tarjeta.
Se requiere 3DS
Error
La autenticación mediante 3D Secure es obligatoria, pero la solicitud de búsqueda de 3D Secure falla y devuelve un error de procesamiento. Los pagos se rechazarán con un código de error card_declined. Las reglas de Radar solicitan la autenticación mediante 3D Secure para esta tarjeta de forma predeterminada.
Compatible con 3DS
Aceptada
La autenticación mediante 3D Secure se puede hacer de todos modos, pero no es obligatoria. Las reglas de Radar no te solicitarán la autenticación mediante 3D Secure para esta tarjeta de forma predeterminada.
Compatible con 3DS
Error
La autenticación mediante 3D Secure se puede hacer de todos modos, pero no es obligatoria. Sin embargo, los intentos de autenticación mediante 3D Secure dan como resultado un error de procesamiento. Las reglas de Radar no solicitan la autenticación mediante 3D Secure para esta tarjeta de forma predeterminada.
Compatible con 3DS
Tarjeta no inscrita
3D Secure es compatible con esta tarjeta, pero la tarjeta no está inscrita en 3D Secure. Incluso si las reglas de Radar solicitan 3D Secure, no se le pedirá al cliente que se autentique. Las reglas de Radar no solicitan la autenticación mediante 3D Secure para esta tarjeta de forma predeterminada.
No se admite 3DS
No se acepta 3D Secure en esta tarjeta y no se puede invocar. El PaymentIntent o SetupIntent continúa sin que se realice la autenticación.
Flujos de comprobación de 3D Secure para móviles
Hay disponibles varios flujos de comprobación para la autenticación de pagos móviles, en los que el cliente tiene que interactuar con las indicaciones de la interfaz de usuario. Utiliza las tarjetas de prueba de esta sección para activar un flujo de comprobación específico para la prueba. Estas tarjetas no son útiles para formularios de pagos basados en navegadores ni en llamadas a la API. En estos entornos, las tarjetas funcionan, pero no generan ningún comportamiento especial. Como no son útiles en las llamadas a la API, no ofrecemos valores PaymentMethod ni Token con los que hacer pruebas.
Flujo de comprobación
Número
Detalles
Fuera de banda
La autenticación mediante 3D Secure 2 debe realizarse en todas las transacciones. Activa el flujo de comprobación con la IU de fuera de banda.
Código de acceso de un solo uso
La autenticación mediante 3D Secure 2 debe completarse en todas las transacciones. Activa el flujo de comprobación con la interfaz de usuario de código de acceso de un solo uso.
Selección única
La autenticación mediante 3D Secure 2 debe realizarse en todas las transacciones. Activa el flujo de comprobación con la IU de selección única.
Selección múltiple
La autenticación mediante 3D Secure 2 debe realizarse en todas las transacciones. Activa el flujo de comprobación con la IU de selección múltiple.
Pagos con PIN
Utiliza las tarjetas de prueba en esta sección para simular pagos en persona exitosos cuando se utiliza un PIN. Hay muchas otras opciones para probar los pagos en persona, incluido un lector simulado y tarjetas de prueba físicas. Consulta Stripe Terminal de prueba para obtener más información.
Descripción
Número
Detalles
PIN sin conexión
Esta tarjeta simula un pago en el que se le solicita al titular un PIN fuera de línea que el titular introduce. En el cargo resultante, cardholder_verification_method está establecido en offline_pin.
Reintento de PIN sin conexión
Simula un flujo de reintento activado por la SCA, en el que falla el cargo inicial sin contacto del titular de la tarjeta y el lector le solicita al usuario que inserte la tarjeta e introduzca su PIN fuera de línea. En el cargo resultante, cardholder_verification_method está establecido en offline_pin.
PIN en línea
Esta tarjeta simula un pago en el que al titular se le solicita un PIN en línea y debe introducirlo. El cargo resultante tiene un cardholder_verification_method establecido en online_pin.
Reintento de PIN en línea
Simula un flujo de reintento activado por la SCA, en el que el cargo inicial sin contacto del titular de la tarjeta falla y el lector le solicita al usuario que inserte la tarjeta e introduzca su PIN en línea. El cargo resultante tiene un cardholder_verification_method establecido en online_pin.
Si tus solicitudes en modo de prueba comienzan a recibir errores HTTP 429, haz solicitudes menos frecuentes. Estos errores provienen de nuestro limitador de velocidad, que es más estricto en modo de prueba que en modo activo.
No te recomendamos que hagas la prueba de carga de tu integración con la API de Stripe en modo de prueba. Esto se debe a que, en este modo, el limitador de carga es más estricto y, por lo tanto, podrías ver errores que no verías en el modo de producción. Si quieres buscar otras opciones, consulta pruebas de carga.
Pagos sin tarjeta
Cada vez que uses un método de pago de prueba sin tarjeta, usa las claves de prueba de la API en todas las llamadas a la API, tanto si ofreces un formulario de pago que puedas probar de forma interactiva como si escribes código de prueba.
Los métodos de pago tienen diferentes procedimientos de prueba:
Enviar correos electrónicos de transacción en modo de prueba
Después de recoger los datos de la cuenta bancaria y aceptar un mandato, envía la confirmación del mandato y los correos electrónicos de verificación de microdepósito en el modo de prueba. Para ello, proporciona un correo electrónico en el campo payment_method_data.billing_details[email] con el formato {any-prefix}+test_email@{any_domain} al recopilar los datos del método de pago.
Stripe proporciona varios números de cuenta de prueba y tokens correspondientes que puedes usar para asegurarte de que tu integración de las cuentas bancarias introducidas manualmente esté lista para la producción.
Account number
Token
Routing number
Behavior
000123456789
pm_usBankAccount_success
110000000
El pago se efectúa con éxito.
000111111113
pm_usBankAccount_accountClosed
110000000
El pago falla porque la cuenta está cerrada.
000111111116
pm_usBankAccount_noAccount
110000000
El pago falla porque no se encuentra ninguna cuenta.
000222222227
pm_usBankAccount_insufficientFunds
110000000
El pago falla por insuficiencia de fondos.
000333333335
pm_usBankAccount_debitNotAuthorized
110000000
El pago falla porque los débitos no están autorizados.
The payment fails due to payment amount causing the account to exceed its weekly payment volume limit.
Antes de que las transacciones de prueba puedan completarse, debes verificar todas las cuentas de prueba que automáticamente completan el pago con éxito o con errores. Para hacerlo, utiliza las cantidades de microdepósito de prueba o los códigos de descripción detallados a continuación.
Cantidades de microdepósitos de prueba y códigos de descripciones
Para imitar diferentes situaciones, utiliza estas cantidades de microdepósitos o los valores de código de descripción 0.01.
Valores de microdepósitos
0,01 valores del código de descripción
Scenario
32 and 45
SM11AA
Simula la verificación de la cuenta.
10 y 11
SM33CC
Simula que excede la cantidad de intentos de verificación permitidos.
40 y 41
SM44DD
Simula un tiempo de espera de microdepósito.
Redireccionamientos
Para poner a prueba la lógica de gestión del redireccionamiento de tu integración simulando un pago que utiliza un flujo de redireccionamiento (por ejemplo, iDEAL), utiliza un método de pago compatible que requiera redireccionamiento.
Para crear un PaymentIntent de prueba que sea procesado correctamente o que dé error: