# Pagos fallidos en Stripe: cómo recuperarlos y dar o quitar el acceso al curso sin hacerlo a mano

> Qué hace Stripe con un pago recurrente fallido, qué estado de suscripción debe dar o quitar el acceso a tu curso o membresía y cómo automatizarlo sin errores.

- URL: https://fcgsystems.es/blog/pagos-fallidos-stripe-acceso-curso/
- Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/)
- Publicado: 2026-09-15 (15 de septiembre de 2026)
- Tema: Automatización · Formato: Breakdown · Lectura: 9 min
- Palabra clave: pagos fallidos stripe (también: recuperar pagos fallidos, quitar acceso al curso si no paga, control de accesos membresía, stripe past_due unpaid, smart retries stripe)

Cuando un pago recurrente falla en Stripe, lo primero no es escribir al alumno: es dejar que Stripe reintente el cobro con Smart Retries y envíe el email para actualizar la tarjeta. El acceso al curso o a la membresía no debería depender de ese fallo puntual, sino del **estado de la suscripción**: se da con `active`, se mantiene o no durante `past_due` según tu política y se quita con `unpaid` o `canceled`.

El problema real en una academia online o una membresía casi nunca es Stripe. Es lo que pasa entre Stripe y la plataforma formativa: alumnos que siguen dentro meses después de dejar de pagar, alumnos que pagan y no tienen acceso porque el aviso no llegó, o alguien del equipo revisando cada semana una lista de impagos para dar y quitar accesos a mano.

Esta guía explica qué hace Stripe por sí solo, qué tiene que decidir tu sistema y cómo montar el circuito para que funcione sin intervención y sin fallar en silencio.

## ¿Por qué falla un pago recurrente?

Porque el banco emisor lo rechaza, y no todos los rechazos son iguales. Para decidir qué hacer conviene separarlos en dos grupos:

| Tipo de rechazo | Ejemplos | ¿Stripe puede reintentarlo? | Qué necesita |
|---|---|---|---|
| Temporal | Fondos insuficientes, fallo puntual del emisor | Sí, con reintentos automáticos | Tiempo y un buen calendario de reintentos |
| Definitivo (*hard decline*) | `lost_card`, `stolen_card`, `incorrect_number`, `authentication_required`, `transaction_not_allowed` | No, hasta que haya un método de pago nuevo | Que el cliente actualice la tarjeta o confirme el pago |

La lista completa de códigos que Stripe no reintenta está en su [documentación de reintentos automáticos](https://docs.stripe.com/billing/revenue-recovery/smart-retries) (consultado en septiembre de 2026). En esos casos los reintentos programados siguen contando, pero el cobro solo se ejecuta cuando Stripe detecta un método de pago nuevo.

`authentication_required` merece atención aparte: aparece cuando el banco exige que el titular confirme el pago (3D Secure). Ningún reintento lo resuelve sin que el alumno haga algo.

## ¿Qué hace Stripe por sí solo cuando falla un cobro?

Bastante, si está configurado. Todo lo siguiente se activa desde el Dashboard, sin código, según la documentación de [recuperación de ingresos](https://docs.stripe.com/billing/revenue-recovery) y de [emails a clientes](https://docs.stripe.com/billing/revenue-recovery/customer-emails) (consultado en septiembre de 2026):

- **Smart Retries.** Reintenta el cobro en los momentos que su modelo considera más probables de éxito, dentro del número de intentos y el plazo que elijas: 1 semana, 2 semanas, 3 semanas, 1 mes o 2 meses. La configuración recomendada por defecto es **8 intentos en 2 semanas**. Si prefieres reglas fijas, puedes definir hasta tres reintentos con días concretos entre ellos.
- **Email de pago fallido.** Con *Send emails when card payments fail* activado, Stripe envía un email tras cada fallo con un enlace para actualizar el método de pago.
- **Email para confirmar pagos.** Para pagos que requieren 3D Secure, puede enviar un enlace a una página alojada por Stripe donde el cliente confirma el cobro.
- **Portal de cliente.** Una página alojada donde el cliente actualiza su método de pago o cancela la suscripción, según lo que permitas en el [portal de cliente](https://docs.stripe.com/customer-management) (consultado en septiembre de 2026).
- **Actualización automática de tarjetas.** Stripe actualiza la tarjeta guardada cuando el cliente recibe un número nuevo.

Y una decisión que tienes que tomar tú en la configuración de pagos fallidos: **qué pasa con la suscripción cuando se agotan los reintentos**.

| Opción al agotar reintentos | Estado final | Qué implica |
|---|---|---|
| Cancelar la suscripción | `canceled` | Estado terminal. Para volver, el alumno necesita una suscripción nueva |
| Marcar como no pagada | `unpaid` | La suscripción sigue existiendo, se generan facturas en borrador y no se intenta cobrar |
| Dejarla vencida | `past_due` | Se siguen generando facturas y se cobra según la configuración de reintentos |

## ¿Qué estado de la suscripción debe dar o quitar el acceso al curso?

Aquí está la decisión que Stripe no toma por ti. La regla que aplico en cualquier sistema de accesos es la misma que en la guía de [sistemas para negocios digitales](https://fcgsystems.es/blog/sistemas-para-negocios-digitales/): **el pago manda y el acceso obedece**. La pasarela es la fuente de verdad del estado del cobro y la plataforma formativa solo refleja ese estado.

Traducido a los estados de una suscripción en Stripe, según su documentación de [webhooks de suscripciones](https://docs.stripe.com/billing/subscriptions/webhooks) (consultado en septiembre de 2026):

| Estado | Qué significa | Acción recomendada sobre el acceso |
|---|---|---|
| `trialing` | Periodo de prueba | Dar acceso |
| `active` | Suscripción al corriente | Dar acceso |
| `incomplete` | El primer pago no se ha completado (tiene 23 horas) o requiere acción | No dar acceso todavía |
| `incomplete_expired` | El primer pago no se completó en 23 horas | No dar acceso |
| `past_due` | El último pago falló o no se intentó; puede haber reintentos | Decisión de negocio: mantener con aviso o restringir |
| `unpaid` | Reintentos agotados, sin nuevos intentos de cobro | Quitar acceso (lo indica Stripe) |
| `canceled` | Suscripción cancelada, estado terminal | Quitar acceso (lo indica Stripe) |
| `paused` | Prueba terminada sin método de pago | No dar acceso |

`past_due` es la fila que más discusiones genera. Quitar el acceso al primer fallo castiga a alumnos con una tarjeta caducada que habrían pagado en dos días. Mantenerlo indefinidamente regala el producto. Lo razonable es escribir la política (por ejemplo, acceso completo mientras duran los reintentos y aviso visible dentro de la plataforma) y que el sistema la aplique igual para todos.

## ¿Qué eventos de Stripe hay que escuchar?

Stripe notifica los cambios con eventos de webhook. Para controlar accesos bastan cuatro:

- `invoice.paid`: la factura se ha pagado. Stripe indica que puedes dar acceso al recibirlo si la suscripción está `active`.
- `invoice.payment_failed`: un cobro ha fallado. Su campo `attempt_count` indica cuántos intentos van.
- `customer.subscription.updated`: la suscripción ha cambiado, incluidos los cambios de estado como el paso a `past_due` o `unpaid`.
- `customer.subscription.deleted`: la suscripción ha terminado.

Tres detalles de la [documentación de webhooks](https://docs.stripe.com/webhooks) (consultado en septiembre de 2026) que evitan la mayoría de errores:

1. **Stripe no garantiza el orden de los eventos.** No construyas la lógica suponiendo que `invoice.paid` llega antes o después de `customer.subscription.updated`. Ante cualquier evento, consulta el estado actual de la suscripción y decide con ese dato.
2. **El mismo evento puede llegar más de una vez.** Guarda los identificadores de evento procesados y descarta los repetidos.
3. **Si tu endpoint no responde bien, Stripe reintenta la entrega hasta tres días** en modo live con retroceso exponencial. Responde con un `2xx` rápido antes de hacer trabajo pesado y verifica la firma de cada evento.

## Cómo montar el control de accesos paso a paso

### 1. Configura la recuperación en Stripe antes de automatizar nada

Activa Smart Retries, los emails de pago fallido y de confirmación de pago, y elige qué pasa al agotar los reintentos. Buena parte de los cobros se recuperan aquí sin que tu sistema haga nada.

### 2. Escribe la política de acceso

Una tabla como la anterior, con tu decisión sobre `past_due`, firmada por quien decide en el negocio. Sin esta pieza, la automatización solo reproduce más rápido la improvisación de siempre.

### 3. Relaciona cliente de Stripe y alumno con un identificador, no con el email

Guarda el ID de cliente de Stripe en la ficha del alumno (en el CRM o en la plataforma) desde la primera compra. El email cambia, se escribe con mayúsculas distintas o se usa uno diferente para pagar y para entrar al curso. Un identificador estable evita dar acceso a la persona equivocada o no encontrar a nadie.

### 4. Construye el flujo que aplica la regla

Da igual que viva en n8n, en Make o en un servicio propio. El flujo mínimo:

1. Recibe el evento y verifica la firma.
2. Comprueba si ese ID de evento ya se procesó. Si es así, termina.
3. Consulta el estado actual de la suscripción en Stripe.
4. Busca al alumno por el ID de cliente.
5. Aplica la política: dar, mantener o quitar acceso.
6. Registra qué hizo, con qué evento y con qué resultado.

El paso 5 tiene que ser idempotente: quitar el acceso a quien ya no lo tiene no debe dar error ni duplicar nada. Si el flujo corre en n8n y los eventos no llegan, revisa las causas habituales en [por qué un webhook de n8n no funciona](https://fcgsystems.es/blog/webhook-n8n-no-funciona/).

### 5. Reconciliación diaria

Una vez al día, compara las suscripciones activas en Stripe con los accesos activos en la plataforma. Cualquier diferencia es un fallo, aunque ninguna herramienta haya marcado error: alguien con acceso sin suscripción, o alguien pagando sin acceso. Es la comprobación que más fallos silenciosos destapa, como explico en [automatizaciones que fallan en silencio](https://fcgsystems.es/blog/automatizaciones-que-fallan-en-silencio/).

### 6. Avisos con responsable

Si el flujo falla o la reconciliación encuentra diferencias, alguien concreto tiene que enterarse el mismo día.

## Errores comunes en el control de accesos por pago

- **Quitar el acceso con `invoice.payment_failed`.** El primer fallo no significa impago: con Smart Retries puede quedar todavía una serie de reintentos por delante.
- **Dar acceso en cuanto el alumno vuelve de la página de pago.** El pago puede requerir confirmación o fallar después. El acceso se da con el estado de la suscripción, no con la redirección.
- **Depender del orden de los eventos.** Si la lógica solo funciona cuando los eventos llegan en un orden concreto, fallará de vez en cuando y nadie sabrá por qué.
- **No descartar eventos duplicados.** Un reintento de entrega puede enviar dos veces el email de bienvenida o crear dos altas.
- **Buscar al alumno por email.** Funciona hasta el primer alumno que paga con el email de su empresa.
- **No reconciliar nunca.** Los accesos que sobran o faltan se descubren cuando alguien se queja, meses después.
- **Revisar impagos a mano cada semana.** Además del tiempo, garantiza que la regla se aplica distinto según quién la revise.

## ¿Y si la plataforma formativa no permite dar o quitar acceso por API?

Entonces el cuello de botella no está en Stripe. Las opciones, de menos a más trabajo: usar la integración nativa entre la plataforma y la pasarela si existe y cubre tu política, gestionar el acceso en una capa que sí controlas (un área de miembros o un portal propio) o cambiar de plataforma cuando el control de accesos es crítico para el negocio. Si la operación ya no cabe en las herramientas que tienes, el artículo sobre [cuándo pasar de no-code a software propio](https://fcgsystems.es/blog/de-no-code-a-software-a-medida/) ayuda a decidir.

## Checklist: control de accesos y pagos fallidos

- Smart Retries o reglas de reintento configuradas.
- Emails de pago fallido y de confirmación de pago activados.
- Decidido qué pasa con la suscripción al agotar los reintentos.
- Política de acceso escrita para cada estado, incluido `past_due`.
- ID de cliente de Stripe guardado en la ficha de cada alumno.
- Firma de los webhooks verificada.
- Eventos duplicados descartados por su ID.
- La lógica consulta el estado actual y no depende del orden de los eventos.
- Acciones de dar y quitar acceso idempotentes.
- Log de cada decisión de acceso.
- Reconciliación diaria entre suscripciones activas y accesos activos.
- Un responsable recibe los avisos de fallo.

## ¿Cuándo conviene delegarlo?

Si tienes pocas suscripciones y la plataforma formativa trae integración nativa con Stripe, configura bien los reintentos y los emails y probablemente sea suficiente.

Conviene que lo construya alguien con experiencia en sistemas cuando el acceso depende de varias herramientas (pasarela, CRM, plataforma, comunidad), cuando hay más de un producto o plan, cuando ya has encontrado alumnos con acceso sin pagar o cuando alguien del equipo dedica horas cada semana a revisarlo. El control de accesos es uno de los ejemplos típicos de un Automation Sprint de 1 a 3 semanas dentro del servicio de [automatización de procesos](https://fcgsystems.es/servicios/automatizacion-de-procesos/): diseño, integración, pruebas, logs, documentación y traspaso. Si la plataforma no da más de sí, lo planteamos como [software a medida](https://fcgsystems.es/servicios/software-a-medida/).

Si tus accesos y tus cobros no cuadran y no sabes desde cuándo, [cuéntame qué proceso os está frenando](https://fcgsystems.es/contacto/) y lo revisamos.

## Preguntas frecuentes

### ¿Stripe reintenta automáticamente los pagos fallidos de una suscripción?

Sí, si lo configuras en Billing. Smart Retries elige el momento de cada reintento dentro del número de intentos y el plazo que definas; la configuración recomendada por Stripe es 8 intentos en 2 semanas. No reintenta cuando el banco devuelve un rechazo definitivo, como una tarjeta robada o una autenticación requerida, hasta que el cliente aporta un método de pago nuevo.

### ¿Cuándo hay que quitar el acceso a un alumno que no ha pagado?

La documentación de Stripe indica revocar el acceso cuando la suscripción pasa a canceled o unpaid, porque en ese punto ya se han agotado los reintentos. Mientras está en past_due la decisión es de negocio: muchos proyectos mantienen el acceso con un aviso durante los reintentos. Lo importante es que la regla esté escrita y la aplique el sistema, no una persona.

### ¿Qué diferencia hay entre past_due y unpaid en Stripe?

past_due significa que el último pago falló o no se intentó y que Stripe puede seguir reintentando. unpaid solo aparece si lo eliges en la configuración de pagos fallidos: la suscripción sigue existiendo y genera facturas, pero ya no se intenta cobrar. Al terminar los reintentos puedes elegir entre cancelar, marcar como unpaid o dejarla en past_due.

### ¿Qué hago con los pagos que fallan por authentication_required?

Stripe no puede reintentarlos por su cuenta porque requieren que el cliente confirme el pago. Activa el email con enlace alojado por Stripe para confirmar pagos que lo necesiten y avisa al alumno desde tu propio canal, porque sin su intervención ese cobro no se va a completar.

### ¿Se puede automatizar el control de accesos con n8n o Make?

Sí, siempre que tu plataforma formativa permita dar y quitar acceso por API o por integración. El flujo escucha los eventos de Stripe, verifica la firma, ignora eventos ya procesados, consulta el estado actual de la suscripción y aplica la regla de acceso. Sin reconciliación diaria y sin logs, ese flujo acabará fallando en silencio.

## Servicios relacionados

- [Academia y automatización](https://fcgsystems.es/servicios/automatizacion-de-procesos/): El alumno paga y entra solo. Altas, accesos, renovaciones y bajas sin que nadie lo haga a mano.
- [CRM y software a medida](https://fcgsystems.es/servicios/software-a-medida/): CRM a medida para setters y closers: cada lead con su origen, su responsable y su historial.

## Contacto

Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable.