Si un grupo de membresía tiene más de una variante (por ejemplo, «Estándar» a 60 €/mes y «Premium» a 90 €/mes), un cliente puede cambiar entre ellas en cualquier momento: no hace falta cancelar la membresía actual y volver a comprar. Usted también puede cambiar la variante de un cliente desde el área de administración. En la aplicación, el botón que hace esto se llama Cambiar variante. Este artículo explica exactamente qué ocurre según la variante a la que cambie.
Quién puede cambiar la variante
El cliente, desde su propio perfil. Encontrará un botón Cambiar variante en el detalle de la membresía.
El estudio, desde el área de administración. Abra el detalle de la membresía del cliente y verá el mismo botón Cambiar variante. A diferencia del cliente, usted también ve las variantes archivadas y ocultas en la lista, así que puede pasar a un cliente a una variante que ya no está en la oferta pública.
Cuatro tipos de cambio, cada uno se comporta de forma distinta
Lo que hace un cambio depende de qué tipo de cambio sea. Hay cuatro escenarios:
Tipo de cambio | Ejemplo | Qué ocurre hoy |
Subida (mismo intervalo, precio más alto) | Estándar mensual 60 € → Premium mensual 90 € | Al cliente se le cobra la diferencia prorrateada por los días restantes, de inmediato. El ciclo de facturación no cambia. |
Rebaja programada (mismo intervalo, precio más bajo) | Premium mensual 90 € → Estándar mensual 60 € | Hoy no se cobra nada. El cambio se aplica automáticamente en la siguiente renovación regular. El cliente sigue pagando el precio anterior hasta el final del período actual. |
Cambio de intervalo (duración de período distinta) | Mensual 90 € → Anual 900 € | El ciclo se reinicia, Stripe cobra el precio completo del nuevo período de inmediato y un nuevo ciclo empieza hoy. |
Mismo precio (variante distinta, mismo importe) | «Pro v1» mensual 75 € → «Pro v2» mensual 75 € | El cambio ocurre de inmediato sin ningún pago. El ciclo se mantiene igual. |
Detalles a continuación.
Cuándo es posible un cambio
La membresía actual debe estar Activa (en raras ocasiones también Pendiente de inicio, aunque en la versión actual esto prácticamente nunca se aplica a las membresías recurrentes, que empiezan en cuanto se pagan; este estado se aplica sobre todo a las membresías únicas).
La membresía no debe estar en proceso de cancelación. Si el cliente ha hecho clic en «Cancelar al final del período», primero tiene que revertirlo (hacer clic en Mantener membresía) antes de poder cambiar.
La membresía no debe estar pausada, no pagada ni en el estado «Pendiente de pago» (una verificación 3D Secure sin terminar).
Deben pasar al menos 24 horas entre cambios de variante. El reloj empieza desde el último cambio realizado por el cliente o el estudio, y el simple hecho de programar un cambio también cuenta (Escenario B). Si un cliente lo intenta antes, verá «La variante solo se puede cambiar una vez cada 24 horas. Inténtelo de nuevo más adelante.» Cuidado con un malentendido habitual: cancelar un cambio programado no tiene límite de tiempo (puede cancelarlo cuando quiera), pero un nuevo cambio después solo es posible 24 horas después del último cambio, y la programación original cuenta para ese plazo. En cambio, la aplicación automática de una rebaja programada en la renovación prácticamente nunca estorba, porque para entonces la programación suele tener más de 24 horas.
La variante de destino debe estar en el mismo grupo. No se puede cambiar entre grupos: para pasar a un cliente a otro grupo, tiene que cancelar la membresía actual y comprar una nueva.
La variante de destino debe usar la misma moneda que la actual. Si la variante de destino está en otra moneda (las variantes de un mismo grupo suelen compartir moneda, pero en casos raros pueden diferir), Zenamu rechaza el cambio con «Esta membresía no se puede cambiar en su estado actual. El cambio de variante solo está disponible para membresías activas.» El motivo es técnico: la moneda de una membresía recurrente existente no se puede cambiar. La única forma de sortearlo es cancelar la membresía anterior y comprar una nueva en la moneda de destino.
Cada escenario en detalle
Escenario A: Subida (mismo intervalo, precio más alto)
Ejemplo: Un cliente paga 60 €/mes por «Estándar» y lleva 15 días de un período de 30 días. Cambia a «Premium» a 90 €/mes.
Qué ocurre:
Stripe crea una factura con dos conceptos: un crédito por la parte no utilizada de Estándar (−30 € por 15 días de 60 €) y el importe prorrateado por 15 días de Premium (+45 € de 90 €). Importe neto a pagar: 15 €.
Stripe cobra los 15 € de inmediato a la tarjeta del cliente. No queda ningún crédito a favor en la cuenta del cliente: el crédito se consume directamente dentro de esta factura.
El ciclo de facturación NO cambia. El próximo pago regular (los 90 € completos) se realiza en la fecha original, siguiendo el calendario original en lugar de un mes después del cambio.
Durante el cambio, el cliente ve todo el desglose: la variante actual, la nueva variante, la diferencia prorrateada a pagar hoy y la fecha del próximo pago regular.
¿Por qué solo la diferencia prorrateada y no el nuevo precio completo? El cliente ya ha pagado el período actual, así que no hay motivo para volver a cobrarle el nuevo precio entero. El ciclo simplemente continúa en su fecha original: el cliente no siente que ha «reiniciado» el período y que tiene que pagar el importe completo otra vez de inmediato.
¿Y si el pago no se puede cobrar de inmediato? Si el banco del cliente lo rechaza (fondos insuficientes, tarjeta caducada, 3D Secure requerido), Stripe no confirma el pago y el cambio no se realiza. El cliente ve un error genérico que indica que el pago no se pudo completar, sin el motivo concreto del banco. Puede consultar el motivo en el panel de Stripe (en la factura o la suscripción correspondiente). El cliente tiene entonces que arreglar su tarjeta (con Gestionar método de pago en su perfil; consulte Cómo compra un cliente una membresía recurrente) y volver a iniciar el cambio. Esta exigencia es intencionada: si Zenamu cambiara la variante pero Stripe no confirmara el pago, la facturación acabaría hecha un lío. (Stripe está configurado para revertir todo el cambio por sí mismo cuando un pago no se confirma.)
Escenario B: Rebaja programada (mismo intervalo, precio más bajo)
Ejemplo: Un cliente paga 90 €/mes por «Premium» y lleva 15 días de un período de 30 días. Cambia a «Estándar» a 60 €/mes.
Qué ocurre:
Hoy no se cobra nada. Ningún pago hoy, ningún crédito.
El cliente sigue pagando 90 € durante los 15 días restantes del período actual (ya pagado, sigue usando Premium).
En la siguiente fecha de renovación, Zenamu cambia automáticamente la variante a Estándar y Stripe cobra 60 € (no 90 €).
Tanto el cliente como el estudio ven un aviso sobre el cambio programado en el detalle de la membresía, junto con la fecha en que surte efecto.
El cliente puede cancelar el cambio programado (véase más abajo) antes de esa fecha y volver a Premium.
¿Por qué no hay crédito? El cliente ha pagado el precio completo (más alto) del período actual, así que tiene algo que aprovechar. En lugar de que Stripe devuelva la diferencia como un crédito que luego habría que aplicar a lo largo de los meses siguientes, simplemente espera hasta la siguiente renovación y cobra el nuevo precio (más bajo). Para el cliente es más claro así.
Escenario C: Cambiar el intervalo de facturación
Ejemplo: Un cliente paga 90 € al mes y lleva 15 días de un período de 30 días. Cambia a la variante anual a 900 €.
Qué ocurre:
Stripe reinicia el ciclo de facturación a partir de hoy.
Crea una única factura por 900 € (la tarifa anual) menos un crédito prorrateado por los 15 días no utilizados del mes original (aproximadamente −45 €). Al cliente se le cobran en realidad unos 855 € (el importe neto). Si el nuevo importe es superior al crédito por el resto no utilizado del período anterior, el crédito se aplica directamente a esta factura: no queda ningún saldo. Si, en cambio, el crédito es superior (lo habitual al cambiar de anual a mensual), el crédito sobrante permanece en la cuenta del cliente y se aplica en las renovaciones futuras (véase el párrafo siguiente).
El cliente sigue pagando de forma anual a partir de ahora; la próxima renovación es dentro de un año a partir de hoy.
El mismo principio se aplica a la inversa (anual → mensual): el ciclo se reinicia, y la factura neta equivale al nuevo precio menos el crédito prorrateado por la parte no utilizada del intervalo anterior. Si el cliente cambia poco después de un pago anual, el crédito puede ser considerable, no necesariamente «pequeño».
Por qué el ciclo se reinicia en este caso: El cliente quería explícitamente un intervalo distinto (por ejemplo, pasar a anual por un mejor precio). Reiniciar el ciclo coincide con lo que el cliente espera.
La misma limitación que con una subida: Si el banco del cliente rechaza el pago o requiere 3D Secure, el cambio no se realiza. El cliente actualiza primero su tarjeta y luego vuelve a confirmar el cambio.
Escenario D: Mismo precio, variante distinta
Ejemplo: Un cliente paga 75 €/mes por «Pro v1» y cambia a «Pro v2» a los mismos 75 €/mes.
Qué ocurre:
La variante cambia de inmediato.
Ningún pago, ningún crédito.
El ciclo se mantiene igual: el próximo pago es en la misma fecha, por el mismo importe.
En la práctica esto solo se usa de vez en cuando, por ejemplo tras renombrar una variante o hacer un pequeño cambio cosmético.
La vista previa del desglose antes de confirmar
Antes de que el cliente (o el estudio) haga clic en el botón Cambiar variante para confirmar (la confirmación dentro del cuadro de diálogo), ve una vista previa detallada en el cuadro. Lo que muestra depende del tipo de cambio:
Subida: «Hoy se le cobrarán 15 € (la diferencia prorrateada). El próximo pago regular de 90 € es el 15 de mayo de 2026 (la fecha original).»
Rebaja programada: «Hoy no se cobra nada. La variante cambia a Estándar el 15 de mayo de 2026 (la fecha del próximo pago). A partir de entonces pagará 60 €/mes.»
Cambio de intervalo: «Hoy se le cobrarán 855 € (900 € menos un crédito de 45 € por los 15 días no utilizados). El nuevo ciclo anual empieza hoy: el próximo pago de 900 € es dentro de un año a partir de hoy.»
Mismo precio: «La variante cambia de inmediato, sin ningún cargo nuevo.»
Si el cliente tiene un crédito a favor (que puede surgir, por ejemplo, tras un reembolso emitido como crédito en lugar de a la tarjeta): el importe de la vista previa ya lo tiene en cuenta. Así que si la vista previa muestra «Hoy se le cobrarán 10 €», el cliente paga de verdad 10 €, independientemente de que se aplicara un crédito «entre bastidores». El cliente no ve dos cifras; solo ve la final.
Si Stripe no puede realizar el cálculo por algún motivo (una breve interrupción, por ejemplo), el cliente ve «No se pudo cargar el cálculo del pago. Inténtelo de nuevo en un momento. Si el problema continúa, contacte con el proveedor.» y el botón Cambiar variante queda desactivado. En ese caso, basta con esperar un momento y volver a intentarlo.
Un cambio programado: cómo se muestra en el detalle de la membresía
Cuando una rebaja programada (Escenario B) está en vigor, tanto el cliente como el estudio ven un aviso amarillo/naranja en el detalle de la membresía:
Cambio de variante programado Su variante cambiará a Estándar el 15 de mayo de 2026. Hasta entonces, la variante actual continúa.
[Cancelar el cambio programado]
El botón Cancelar el cambio programado está disponible tanto para el cliente como para el estudio. Una vez confirmado, Zenamu revierte todo a su estado original: no se aplica ningún cambio, el cliente se queda en la variante actual y sigue pagando el mismo precio.
En casos raros, esto puede ocurrir: Si alguien ha editado manualmente el precio de la suscripción directamente en el panel de Stripe mientras tanto, Zenamu detecta el desajuste cuando usted cancela el cambio programado. En ese caso, el botón rechaza la acción. Abra el panel de Stripe desde el perfil del cliente, compruebe el precio actual de la suscripción y concílielo manualmente con lo que el cliente debería tener.
Importante: cómo funciona el límite de 24 horas después de cancelar un cambio programado: Cancelar un cambio programado no tiene límite de tiempo por sí mismo: puede hacer clic en Cancelar el cambio programado cuando quiera. Pero un nuevo cambio a otra variante solo es posible 24 horas después del último cambio que hicieran el cliente o el estudio, y la programación original del cambio cuenta para ese plazo. En la práctica esto significa: si programa una rebaja y luego la cancela de inmediato, aun así tendrá que esperar antes de poder volver a cambiar. Tras una aplicación automática en la renovación, en cambio, el límite prácticamente nunca se aplica, porque la programación suele tener más de 24 horas.
Qué ven el cliente y el estudio durante el cambio
En el detalle de la membresía, haga clic en Cambiar variante.
Se abre un cuadro de diálogo con la lista de variantes del mismo grupo. La variante actual está marcada como «actual».
El cliente o el estudio elige la variante de destino. El cuadro carga la vista previa del desglose descrita arriba.
Una vez confirmado (el botón Cambiar variante del cuadro de diálogo), Zenamu muestra «Variante cambiada.» (para los escenarios inmediatos) o «El cambio de variante se ha programado para el próximo período de facturación.» (para una rebaja programada).
Después del cambio
El cliente sigue usando la membresía sin interrupción: no hay ningún corte en su acceso a las reservas.
Los límites de reserva pertenecen al grupo, no a la variante. Si el grupo está configurado en máx. 4 reservas por semana, eso se aplica independientemente de la variante.
Zenamu registra el cambio internamente como un evento Variante cambiada (la etiqueta que verá en la actividad del cliente y en Stripe). Con una rebaja programada, se acumulan dos registros de este tipo con el tiempo (ambos etiquetados como Variante cambiada): uno cuando programa el cambio y otro en la siguiente renovación, cuando la rebaja surte efecto de verdad.
El estado de la membresía se actualiza automáticamente en la aplicación tanto para el cliente como para el área de administración: no hace falta actualizar la página.
Casos especiales
¿Y si el grupo solo tiene una variante?
El botón Cambiar variante no aparece, ni para el cliente ni para usted. No hay nada entre lo que cambiar. Si quiere permitir que el cliente cambie, añada al menos una variante más al grupo.
El estudio cambia a un cliente a una variante archivada u oculta
En el área de administración, la lista de variantes también muestra las marcadas como Oculta del público o Archivada. Puede cambiar a un cliente a ellas, por ejemplo, cuando quiere pasarlo a una variante más antigua que mantiene su precio. El cliente no puede ver una variante así por sí mismo; solo usted puede.
¿Y si añade una nueva variante al grupo?
Los clientes existentes verán la nueva variante en la lista cuando hagan clic en Cambiar variante. Pueden cambiar en cualquier momento: no necesitan nada más de usted.
¿Y si oculta o archiva una variante antigua?
Los clientes existentes se quedan en ella hasta que cambian por sí mismos (o hasta que usted los traslada). Desde su punto de vista, nada cambia: siguen pagando el precio original. Ocultar o archivar solo afecta a las nuevas compras: los nuevos interesados no verán la variante.
Cuidado: ¿y si un cliente tiene una rebaja programada y usted archiva la variante mientras tanto? Archivar no tiene ningún efecto sobre un cambio programado que ya está en curso. Desde el momento en que se programó, Stripe tiene almacenado el nuevo precio (más bajo) y cobrará al cliente exactamente ese importe en la siguiente renovación. Tras una renovación correcta, Zenamu pasa al cliente a la variante archivada también a nivel local (verá la variante «archivada» en el detalle de su membresía) y registra el traslado internamente.
Si quiere impedir que la rebaja surta efecto, tiene que cancelar explícitamente el cambio programado de cada cliente afectado antes de la siguiente renovación (el botón Cancelar el cambio programado en el detalle de la membresía). Archivar una variante no es un «interruptor de apagado»: su único propósito es impedir que los clientes nuevos compren la variante; no tiene efecto retroactivo sobre los cambios programados que ya están en curso.
¿Y si el cliente tiene un crédito a favor?
Cambiar de variante no crea créditos a favor: una rebaja programada (Escenario B) lo gestiona de otro modo (sin crédito, solo el nuevo precio a partir de la siguiente renovación). Un cliente solo puede tener un crédito a favor por:
Un cambio de intervalo (Escenario C): un pequeño crédito por la parte no utilizada del período original.
Operaciones manuales en Stripe (por ejemplo, el estudio reembolsó un pago como crédito en lugar de a la tarjeta).
Si existe un crédito a favor, se aplica automáticamente a una de las siguientes transacciones. Para más detalles, consulte el artículo 12: Reembolsos y pagos en disputa.
¿Y si un cliente cambia justo antes del final del período de facturación?
Con una subida, la diferencia prorrateada por los días restantes es pequeña (por ejemplo, 2 € por los últimos 2 días), así que el cargo inmediato es bajo. El cliente ve este importe en el cuadro de diálogo antes de confirmar.
Con una rebaja programada, da igual: se aplica en la siguiente renovación de todos modos.
Para el estudio: cuándo intervenir
Cambiar la variante es, en la gran mayoría de los casos, una acción del cliente. Desde el área de administración, vale la pena planteárselo en estas situaciones:
Un cliente le pide que lo cambie a una variante concreta (por ejemplo, una reducción de precio acordada).
Está archivando una variante antigua y quiere pasar a los clientes a una nueva en bloque (aunque incluso entonces es mejor hablar primero con el cliente y dejar que cambie por sí mismo).
Un cliente no puede o no quiere usar su perfil (una ausencia prolongada, por ejemplo) y usted gestiona su cuenta manualmente.
Recomendación: Antes de cambiar la variante de un cliente desde el área de administración, indíquele siempre con antelación lo que ocurrirá: si le cobraremos la diferencia prorrateada de inmediato (una subida), programaremos el cambio para la siguiente renovación (una rebaja) o reiniciaremos el ciclo con un pago completo (un cambio de intervalo). El cliente debe estar al tanto del cargo de antemano, aunque Stripe le envíe un correo de confirmación automáticamente.
Preguntas frecuentes
Un cliente cambia todos los días. ¿Por qué no funciona? El límite de 24 horas impide ese tipo de experimentación. Tras el último cambio realizado por el cliente o el estudio, deben pasar 24 horas antes de que sea posible otro cambio. Programar un cambio también cuenta para este límite (Escenario B). Si un cliente lo intenta antes, Zenamu muestra «La variante solo se puede cambiar una vez cada 24 horas. Inténtelo de nuevo más adelante.» Nota: aunque cancele el cambio programado mientras tanto (lo cual no tiene límite de tiempo), un nuevo cambio aún espera 24 horas desde la programación original. La aplicación automática en la renovación, en cambio, prácticamente nunca estorba, porque la programación suele tener más de 24 horas.
¿Puedo crear un «paquete» para un cliente con 3 variantes distintas a la vez? No: un cliente solo puede tener una variante activa en un grupo. Si quiere varios derechos simultáneos, cree varios grupos (el cliente puede tener entonces una variante de cada grupo).
Un cliente cambió su variante por error: solo quería comparar precios. ¿Cómo lo deshago?
Si fue una subida: volver a la variante original (más barata) entra dentro del Escenario B: rebaja programada. El cliente tiene que esperar 24 horas e iniciar el cambio de vuelta; el cambio se aplica entonces solo en la siguiente fecha de renovación (hasta entonces paga el precio más alto). No hay reembolso inmediato.
Si fue un cambio de intervalo: volver atrás entra dentro del Escenario C: cambio de intervalo otra vez (el ciclo se reinicia, Stripe calcula el ajuste prorrateado). El cliente puede hacerlo una vez superado el límite de 24 horas.
Si fue una rebaja programada: el cliente puede hacer clic de inmediato en Cancelar el cambio programado en el detalle de la membresía y volver al estado original. Sin esperas, sin pago.
Un cliente me dice que Stripe le cobró el importe completo tras un cambio de variante. ¿Es correcto? No, salvo que fuera un cambio de intervalo. Con una subida (mismo intervalo, precio más alto), solo debería cobrarse la diferencia prorrateada por los días restantes, no el nuevo precio completo. Si el cliente informa de otra cosa, compruebe la factura concreta en el panel de Stripe desde su perfil: verá el desglose exacto de los conceptos (crédito por los días no utilizados + el nuevo importe prorrateado). Stripe solo cobra el nuevo precio completo en un cambio de intervalo.
¿Cuándo surte efecto exactamente una rebaja programada? En la siguiente fecha de renovación según el ciclo actual. Si el ciclo de un cliente es el día 15 del mes y programó una rebaja el 5 de mayo, el cambio se aplica el 15 de mayo (la siguiente renovación). Puede ver la fecha en el aviso del detalle de la membresía.
¿Puedo programar una rebaja para cualquier fecha futura que quiera? No: una rebaja programada siempre surte efecto en la fecha de la siguiente renovación regular. No puede fijar una fecha propia.
Artículos relacionados
Gestionar a los miembros existentes: todas las demás acciones que puede realizar en una membresía
Cambiar el precio para los miembros existentes: cuando quiere cambiar el precio de toda una variante, en lugar de cambiar a un cliente concreto
Códigos de descuento y membresías recurrentes: los descuentos no se vuelven a aplicar cuando se cambia de variante
Cuando un pago falla: qué ocurre si un pago falla en una renovación programada