Cada membresía recurrente en Zenamu mantiene un registro interno completo de cada evento importante: desde el momento en que se crea, pasando por cada renovación, pausa y cancelación, hasta cualquier reembolso. Este registro es su historial completo y su red de seguridad para resolver disputas y llevar la contabilidad. Este artículo explica dónde encontrar la actividad de una membresía y cómo leer cada tipo de evento.

Dónde encontrar la actividad de una membresía

Abra el detalle de la membresía de un cliente en el área de administración y verá:

El estado actual de la membresía (activa, pausada, pendiente de pago, cancelada, etc.), la fecha de la próxima renovación y, si algo falló, los detalles sobre el período de gracia y el pago fallido.
La sección Pedidos: una lista de los documentos emitidos para esta membresía (fecha de creación, fecha de pago, estado del pago, importe, descripción y un enlace al detalle del documento). Es su principal fuente de información sobre los pagos correctos concretos, y a la vez sirve de base para su contabilidad.

En su perfil (en Mis membresías compradas → detalle), el cliente ve el mismo estado y la misma lista de sus pedidos.

Importante: Zenamu todavía no tiene una pantalla específica de «Historial de renovaciones» que detalle eventos concretos como las pausas, los cambios de variante o las correcciones. Esos eventos se almacenan en un registro interno de la base de datos y se reflejan en su panel de Stripe (en Subscriptions, Invoices y Events). En la aplicación tiene tres lugares con los que trabajar directamente: el estado actual de la membresía, la lista de documentos (Pedidos) y la actividad del cliente, donde los principales eventos se describen en lenguaje sencillo (renovada, pago fallido, pausada o pausada automáticamente, reanudada, cancelada por el cliente, cancelada del lado de Stripe o al final del período). Para la secuencia detallada de cada evento concreto, consulte Stripe. A continuación describimos los tipos de eventos que el sistema registra, para que tengan sentido cuando vaya a buscarlos.

Los tipos de eventos que el sistema registra

Cada evento interno tiene un tipo, una fecha y, a menudo, algunos detalles adicionales (un importe, un motivo, el ID del registro relacionado en Stripe).

Membresía creada (primera compra)

La primera compra correcta de una membresía aparece como la creación de la membresía (estado activa, o brevemente pendiente de pago) y como el primer documento de la sección Pedidos. De él puede ver la fecha, la variante que eligió el cliente y el primer importe cobrado.

Renovación correcta

El sistema registra cada cobro recurrente correcto. Una renovación incluye:

La fecha y la hora de la renovación.
El importe cobrado.
El período de facturación que cubre el pago (puede rastrearlo en la factura en Stripe).
El documento emitido (un recibo o una factura), que encontrará en la sección Pedidos.

Si el cliente usa un crédito a favor (que puede provenir, por ejemplo, de un reembolso anterior emitido como crédito en lugar de a la tarjeta) y cubre todo el pago del período, la renovación se realiza igualmente —Zenamu la registra internamente y la membresía continúa—, pero no se crea ningún documento contable para ella. No se cobró nada a la tarjeta, así que no hay nada que documentar. No encontrará ningún documento para ese período en la sección Pedidos ni en la exportación para su contable. El crédito del cliente se reduce en el precio del período.

Renovación fallida

El sistema registra cada intento de Stripe de cobrar un pago que no tuvo éxito (los reintentos automáticos de Stripe, un reintento manual, etc.).

La fecha y la hora del intento.
El motivo del fallo (el código del banco: fondos insuficientes, rechazada, tarjeta caducada, verificación requerida, etc.).

Una sola renovación fallida puede generar varios registros (Stripe hace varios intentos durante el período de gracia). El mejor sitio para rastrear estos intentos y sus códigos es la factura en su panel de Stripe.

El inicio del período de gracia es un evento interno aparte; además, la fecha en que termina el período de gracia (normalmente 7 días después del fallo) aparece directamente en el área de administración, como parte del aviso de pago fallido de la membresía.

Membresía pausada

Esto se registra cada vez que se pausa una membresía. Puede ver que una membresía está pausada directamente desde su estado en el área de administración. Hay dos casos:

Pausa automática (porque el plan del estudio se redujo). Una nota explicativa que describe este motivo se guarda con el registro.
Pausa manual (desde el área de administración). Se guarda sin nota: no se introduce ningún motivo.

La actividad del cliente también distingue si la membresía se pausó (manualmente) o se pausó automáticamente. Esta diferencia es importante, porque determina si la membresía se renueva automáticamente cuando más adelante vuelve al plan Ultimate (solo lo hacen las membresías pausadas automáticamente).

Membresía reanudada

Esto se registra cuando se vuelve a poner en marcha una membresía pausada. El motivo distingue si fue:

«Reanudada automáticamente: el estudio volvió a Ultimate»: automáticamente, después de que el estudio volviera al plan Ultimate.
Una reanudación manual desde el área de administración o desde el perfil del cliente.

Cambio de variante

Se crea cuando se cambia a un cliente de una variante a otra. En la actividad del cliente, la aplicación etiqueta este evento como Variante cambiada.

La fecha.
Variante anterior → variante nueva.
El tipo de cambio: una subida de precio, una rebaja de precio programada, un cambio de intervalo de facturación o el mismo precio (la variante se renombró, etc.).
Según el escenario: para una subida de precio, aparece una factura inmediata por la diferencia prorrateada por los días restantes (la fecha de la próxima renovación se mantiene igual); para una rebaja de precio programada, no se crea ningún documento el día del cambio: el área de administración muestra un banner «Cambio programado a partir del {{fecha}}» en la membresía, y el cambio se aplica solo en la siguiente renovación; para un cambio de intervalo de facturación, el ciclo se reinicia y se crea una única factura neta (el nuevo precio menos un crédito prorrateado por la parte no utilizada del período anterior).

Puede ver quién hizo el cambio en la actividad del cliente, en el área de administración. Distingue si el cliente cambió la variante desde su perfil o si lo hizo el estudio desde el área de administración (para las acciones del estudio, también se guarda el nombre del miembro del personal).

Cambio de variante programado cancelado

Cuando un cliente (o el estudio en su nombre) cancela un cambio de variante programado previamente (siempre el Escenario B: una rebaja de precio), el banner del cambio programado desaparece del área de administración y el sistema deja una nota interna de la cancelación. No hay consecuencias económicas; la membresía simplemente vuelve a su variante original sin dejar rastro.

Situaciones raras en torno a un cambio de variante programado

De vez en cuando un cliente programa una rebaja de precio, pero ocurre algo inusual entre la programación y el día de la renovación; por ejemplo, el estudio archiva la variante de destino mientras tanto, o elimina el grupo. Zenamu gestiona estas situaciones automáticamente y deja una nota interna de ellas.

Qué puede ocurrir y qué hace Zenamu:

Qué ocurrió	Qué hace Zenamu
El estudio archivó la variante de destino antes de la renovación	El cambio no se aplica. El precio vuelve a la variante original, y el cliente continúa como si nunca hubiera programado la rebaja.
El estudio eliminó por completo la variante de destino	El mismo comportamiento que al archivar.
El estudio archivó o eliminó todo el grupo	El mismo comportamiento; el cliente se queda en la variante original.
Revertir el precio no tiene éxito técnicamente (p. ej. una breve interrupción de Stripe)	Zenamu deja una nota de la situación. Verá un estado de aviso en la membresía en el área de administración. En este caso raro, puede comprobar el precio actual de la suscripción del cliente en su panel de Stripe y ajustarlo manualmente si es necesario.

Estas situaciones son muy raras (normalmente menos del 1 % de los cambios programados). En la gran mayoría de los casos, el cambio se realiza exactamente como el cliente quería el día en que lo programó.

Precio actualizado

El sistema registra cuándo el estudio aplicó un cambio de precio en bloque a este cliente. El registro lleva:

La fecha.
El precio anterior y el nuevo.
Una nota de que el nuevo precio se aplica solo en la siguiente renovación regular.

Membresía cancelada

Esto se registra en cualquier cancelación: manual (el cliente desde su perfil, el estudio desde el área de administración, o a través del portal de cliente de Stripe) y automática (por Zenamu, tras la caducidad del período de gracia de 7 días). Puede ver que una membresía está cancelada directamente desde su estado en el área de administración (o un banner de «Cancelación al final del período» con una fecha). Además, el registro interno lleva:

La fecha de la cancelación.
El método de cancelación: al final del período actual o inmediatamente.
El motivo de la cancelación (por ejemplo, una cancelación manual al final del período, una cancelación inmediata o una cancelación automática tras la caducidad del período de gracia). Esta descripción es solo orientativa: se almacena internamente en inglés y no es el texto exacto que vería en la aplicación.

Puede ver quién hizo la cancelación. Tanto desde el registro interno como desde la actividad del cliente en el área de administración, puede saber si la membresía la canceló el cliente, el estudio o el sistema tras la caducidad del período de gracia. Para las acciones del estudio, también se guarda el nombre del miembro del personal. Lo que el registro no incluye es un enlace a ningún reembolso. Eso lo encontrará en su panel de Stripe, en Refunds.

La confirmación de pago requerida y los reembolsos aparecen de otra forma

La confirmación de pago requerida (3D Secure) en una renovación se registra como un evento interno, pero el estado de la membresía sigue siendo Activa. Cuando se necesita una verificación adicional en una renovación, Zenamu no la pasa a Pendiente de pago (ese estado se reserva para una primera compra sin terminar; consulte el artículo «Estados de la membresía»). El resultado aparece entonces como una renovación fallida (si el cliente no completa la verificación y Stripe deja de intentarlo) o como una renovación correcta (si la completa a tiempo).

Los reembolsos no se registran como una actividad de la membresía aparte. Un reembolso total lleva a que la membresía se cancele automáticamente; un reembolso parcial no cambia el estado de la membresía. El estado del propio reembolso lo encontrará en el documento (la sección Pedidos) o en su panel de Stripe.

Corrección de una comprobación interna (eventos raros)

Este tipo de registro anota una situación en la que una comprobación interna de Zenamu detectó una discrepancia entre su propio estado y el estado en Stripe y la corrigió o dejó una nota para gestionarla más tarde. Los tipos concretos son:

Pedido de compra pendiente: el cliente compró, Stripe lo confirmó, pero Zenamu no pudo crear el pedido interno. El sistema marca el registro para ponerse al día más tarde.
Pedido de renovación pendiente: lo mismo, para una renovación.
Reembolso pendiente tras una concurrencia: Zenamu canceló una membresía justo en el momento en que Stripe cobró un pago en paralelo. El reembolso automático no ocurrió de inmediato, pero queda anotado para gestionarse más tarde.
Cambio de variante pendiente: un cambio de variante no se completó de forma limpia en alguna fase.
Mensaje para una membresía que ya no existe: Stripe envió un mensaje sobre una membresía que ya no existe en Zenamu (el cliente se eliminó).

Estos son, a grandes rasgos, los cinco más habituales; Zenamu usa varios otros marcadores específicos para concurrencias raras (cuando dos cosas ocurren en el mismo momento). Estas correcciones se ejecutan en segundo plano; una corrección concreta suele estar bien por sí sola: el problema es el mismo marcador repitiéndose en la misma membresía. Si está ante una situación así, contacte con el soporte.

Estas correcciones son informativas y aparecen en el sentido de que el estado de la membresía en Zenamu acaba coincidiendo con Stripe:

Una corrección puntual está bien. Los pequeños desajustes entre Stripe y Zenamu ocurren de vez en cuando.
Un desajuste repetido en el mismo cliente o estudio puede apuntar a un problema más profundo. En su panel de Stripe, compruebe si su cuenta está restringida (en Account requirements) y si todas las suscripciones recientes de este cliente coinciden con lo que ve en Zenamu. Si el desajuste persiste, puede volver a sincronizar manualmente en Stripe (cancelar y crear una nueva suscripción).

Actualizaciones de estado en tiempo real

En el área de administración, el estado de la membresía y la lista de pedidos se actualizan automáticamente, en tiempo real. Eso significa que:

Cuando Stripe envía un mensaje a Zenamu (un pago correcto, un fallo, una cancelación), Zenamu cambia el estado de la membresía en unos segundos y añade cualquier documento nuevo.
El estudio ve el cambio sin tener que actualizar la página.

Un cliente, en su perfil, ve el estado actual solo después de actualizar la página. La interfaz del cliente, por lo general, no usa actualizaciones en tiempo real. Si un cliente contacta con el estudio para preguntar por qué no ve un nuevo pago, sugiérale que actualice la página. En algunas situaciones (justo después de un pago), el navegador del cliente comprueba brevemente el estado en segundo plano, pero, por regla general: actualizar la página = estado actual.

En la mayoría de los casos, ambas partes verán los cambios en unos segundos o un minuto desde el evento real del lado de Stripe.

Cómo usar la actividad de una membresía en la práctica

La combinación del estado de la membresía + la lista de pedidos en Zenamu y su panel de Stripe es útil en varias situaciones:

Explicar un pago concreto a un cliente

Cuando un cliente escribe «¿Por qué se me cobraron 60 € el 14 de abril?», abra la sección Pedidos en su membresía y verá:

La fecha y el estado del pago.
El importe.
Un enlace al detalle del documento (el recibo). Puede rastrear el período de facturación que cubre el pago en la factura en Stripe.

Luego puede responder al cliente con los detalles exactos.

Entender por qué se canceló una membresía

Puede saber que una membresía terminó automáticamente tras pagos fallidos por su estado actual (cancelada / no pagada) y por la ausencia del pago correcto en Pedidos. Para la cronología de los intentos concretos y la fecha en que terminó el período de gracia (normalmente 7 días), consulte la suscripción y las facturas correspondientes en su panel de Stripe. El cliente sabrá entonces que tuvo un período de gracia de 7 días que no aprovechó.

Reembolsar a un cliente por un período no utilizado

En la lista de pedidos puede ver la fecha del último pago correcto; puede ver cuánto tiempo es válida la membresía a partir del estado de la membresía (la fecha de la próxima renovación). Calcule el importe prorrateado por los días no utilizados y emita el reembolso en su panel de Stripe.

Localizar cobros duplicados

Si un cliente afirma que Stripe le cobró dos veces, abra la sección Pedidos (y, por seguridad, también las facturas en Stripe). Verá un solo pago (y el cliente se equivoca) o dos, en cuyo caso puede reembolsar uno de ellos.

Documentación para la contabilidad

La lista de pedidos coincide con su panel de Stripe una a una. Si su contable necesita un comprobante de un pago concreto, abra el detalle del documento (y en Stripe encontrará la facturación completa, la fecha de vencimiento y los datos fiscales).

Preguntas frecuentes

Un cliente me dice que no ve su último pago en su perfil. Unas cuantas posibilidades:

Un crédito cubrió todo el pago (no se movió dinero = no hay documento, véase arriba).
El perfil del cliente no se actualiza en tiempo real: pídale que pruebe a actualizar la página.
El mensaje de Stripe se retrasó; espere un minuto y actualice la página.

¿Puedo exportar la actividad de una membresía? Para la contabilidad, use la exportación de documentos estándar del área de administración (ISDOC o XML de Pohoda). Contiene todas las facturas y cancelaciones que su contable necesita. No encontrará una secuencia detallada de eventos concretos (renovaciones correctas y fallidas, pausas, cambios de variante) como un informe aparte en la aplicación; esos datos viven en la base de datos y en su panel de Stripe. En la mayoría de los casos, su contable no los necesita: trabaja con los documentos.

¿Puedo eliminar el registro de un evento? No. Los registros contables e históricos no se eliminan ni se reescriben a posteriori; solo se añaden otros nuevos junto a ellos. El motivo: el historial tiene que mantenerse completo, tanto para fines contables como para resolver disputas.

¿Y si veo algo que no espero en Stripe o en el estado de la membresía (por ejemplo, el resultado de una corrección de una comprobación interna)? Puede ser una situación en la que una comprobación interna de Zenamu detectó una discrepancia entre su propio estado y el estado en Stripe y la corrigió. Si es algo puntual, está bien (de vez en cuando se pierde un mensaje de Stripe, y la red de seguridad interna lo arregla). Si el desajuste persiste en el mismo cliente, compruebe el estado de su suscripción en su panel de Stripe y compárelo con lo que ve en Zenamu. Si de verdad no coincide, contacte con el soporte, o vuelva a sincronizar manualmente en Stripe (cancele y cree una nueva suscripción).

Historial de renovaciones y actividad de la membresía