Pagos fallidos en Stripe: reintentos, correos y acceso
Qué pasa cuando falla la renovación de una suscripción en Stripe: Smart Retries, correos de pago fallido, qué acceso dar en past_due y cómo probarlo antes.
Read in English →
Cuando falla la renovación de una suscripción en Stripe, la factura queda abierta, la suscripción normalmente pasa a past_due y Stripe reintenta el cobro según el calendario que hayas configurado. Si activas Smart Retries y los correos de pago fallido, Stripe recupera solo una buena parte de esos cobros. A tu app le tocan tres cosas: avisar al cliente, ponerle fácil cambiar la tarjeta y decidir qué acceso conserva hasta que el pago entre o se acaben los reintentos.
En esta guía verás qué opciones elegir, a qué eventos debe reaccionar tu app, una política de acceso razonable y cómo ensayarlo todo en un sandbox.
¿Por qué fallan los cobros de renovación?
La mayoría no son fraude ni clientes enojados. Lo típico es una tarjeta vencida o reemplazada, fondos insuficientes justo el día de la renovación, un banco que pide autenticación o un emisor que rechaza un cargo recurrente que no reconoce. Algunos se resuelven solos en un intento posterior; otros no van a funcionar hasta que el cliente cargue otra tarjeta.
Stripe distingue los dos casos. Con los códigos de rechazo definitivo, como lost_card, stolen_card, incorrect_number o authentication_required, los reintentos programados siguen contando pero no cobran nada hasta que se agrega un método de pago nuevo. Y si no hay ningún método de pago, Stripe no reintenta.
¿Cómo configuras los reintentos automáticos?
En el Dashboard, entra a Billing > Revenue recovery > Retries.
- Activa Smart Retries. Stripe elige los momentos para reintentar según señales de su red. Tú decides cuántos intentos y en qué ventana: 1 semana, 2 semanas, 3 semanas, 1 mes o 2 meses. La configuración que Stripe recomienda por defecto es 8 intentos en 2 semanas.
- O usa un calendario propio. Puedes definir hasta tres reintentos, cada uno a cierta cantidad de días del anterior. Hazlo solo si tienes un motivo, como las fechas de pago de sueldo de tus clientes.
- Elige qué pasa cuando se agotan los reintentos. Las opciones son cancelar la suscripción, marcarla como
unpaid, dejarla enpast_dueo pausarla si es elegible.
Esa última decisión define lo que verá tu app. "Cancelar" termina la suscripción y envía customer.subscription.deleted. "Marcar como impaga" mantiene la suscripción pero deja de intentar cobrar, algo útil si quieres que el cliente vuelva y salde lo pendiente. Cambiar estas opciones solo afecta los reintentos futuros, no los que ya están programados.
¿Qué correos al cliente conviene activar?
En la configuración de correos de revenue recovery puedes hacer que Stripe envíe:
- Correos de pago fallido, después de cada intento fallido, con un enlace para actualizar el método de pago.
- Avisos de tarjeta por vencer, un mes antes de que venza la tarjeta por defecto. Evitan el fallo más evitable de todos.
- Correos de confirmación de pago, para cobros en los que el cliente debe autenticarse (3D Secure).
El enlace de esos correos puede llevar a una página alojada por Stripe o a tu propia página de facturación. Si ya usas el portal de clientes, manda a la gente ahí; en la guía del portal de clientes de Stripe explicamos cómo enlazar directo al flujo de "actualizar tarjeta".
Una trampa al probar: en un sandbox, Stripe solo envía estos correos a direcciones de tu dominio verificado o a miembros del equipo, así que un cliente de prueba con un correo cualquiera nunca recibe nada.
¿Qué debe hacer tu app cuando falla un cobro?
Escucha estos eventos en tu manejador de webhooks:
| Evento | Qué te dice | Qué hacer |
|---|---|---|
invoice.payment_failed | Falló un intento; attempt_count indica cuál | Mostrar un aviso y, si quieres, una notificación dentro de la app |
customer.subscription.updated | Cambió el estado, muchas veces a past_due | Actualizar el estado guardado |
invoice.payment_action_required | El banco pide que el cliente se autentique | Pedirle que confirme el pago |
invoice.paid | Funcionó un reintento o la tarjeta nueva | Quitar el aviso y confirmar que el estado es active |
customer.subscription.deleted | Se agotaron los reintentos y elegiste cancelar | Quitar el acceso |
Si usas las automatizaciones de Stripe, ten en cuenta que la fecha del próximo reintento (next_payment_attempt) viene en los eventos invoice.updated y no en invoice.payment_failed.
Cuando el cliente agrega otra tarjeta, ¿dónde queda?
Stripe reintenta con el primer método de pago que encuentra, en este orden: el método por defecto de la suscripción y después el del cliente. Si la suscripción tiene su propio método por defecto y tú solo actualizas el del cliente, Stripe sigue reintentando con la tarjeta vieja. Actualiza el mismo campo que falló o elimina el método por defecto de la suscripción. El flujo de actualización del portal de clientes ya lo resuelve.
¿Cuánto acceso dejar mientras está en past_due?
No hay una única respuesta correcta, pero decídelo a propósito y déjalo por escrito. Una política común y amable con el cliente:
- Durante los reintentos (
past_due): acceso completo y un aviso fijo con un botón "Actualizar tarjeta". - Cuando fallan los reintentos (
unpaidocanceled): quitar las funciones pagadas, conservar la cuenta y los datos, y mostrar cómo volver a suscribirse. - Nunca borres datos por un pago fallido. Quien arregla su tarjeta una semana después espera encontrar su trabajo.
La documentación de Stripe recomienda quitar el acceso cuando la suscripción pasa a canceled o unpaid. Elijas lo que elijas, aplícalo en el servidor a partir del estado que guardó tu webhook; lo explicamos en limitar funciones por plan en un SaaS. Si el estado guardado no coincide con Stripe, el problema está antes, en la configuración de suscripciones y webhooks.
¿Cómo pruebas los pagos fallidos antes de lanzar?
- En un sandbox, suscribe a un cliente de prueba con una tarjeta de prueba normal y asócialo a un reloj de prueba (test clock).
- Cambia la tarjeta por una de las tarjetas de prueba de Stripe que se rechazan al cobrar.
- Adelanta el reloj más allá de la fecha de renovación. Deberías ver
invoice.payment_failedy el estadopast_due. - Adelanta otra vez para ver los reintentos, luego cambia a una tarjeta que funcione y confirma que llega
invoice.paidy vuelve el acceso. - Repite, pero deja que se agoten los reintentos, y confirma que tu app reacciona al estado final que elegiste.
Respuestas rápidas
¿Smart Retries tiene costo extra? Las funciones de revenue recovery son parte de Stripe Billing. Revisa los precios actuales de Billing para tu cuenta.
¿Conviene que yo también mande correos? Los de Stripe suelen bastar. Lo que más suma es un aviso dentro de la app, porque el cliente lo ve mientras usa el producto.
¿Y el primer cobro de una suscripción? Si falla, la suscripción queda en incomplete, y si nadie paga dentro de 23 horas pasa a incomplete_expired. No des acceso a suscripciones incompletas.
¿Puedo reintentar a mano? Sí. Puedes cobrar una factura abierta desde el Dashboard o la API cuando el cliente ya tiene un método de pago que funciona.
¿Pierdes clientes por tarjetas rechazadas?
Si las renovaciones fallan sin que nadie se entere o hay clientes que pierden el acceso cuando no deberían, el arreglo suele estar a la vez en los reintentos, el webhook y la validación de acceso. Nuestro servicio de pagos con Stripe cubre las tres cosas. También puedes empezar con la revisión gratuita de tu app, leer la documentación de reintentos de Stripe o escribirnos.
