If a membership group has more than one variant (for example "Standard" at €60/month and "Premium" at €90/month), a client can switch between them at any time — there's no need to cancel the current membership and buy again. You can also switch a client's variant for them from the admin area. In the app, the button that does this is labelled Switch plan. This article explains exactly what happens depending on which variant you're switching to.
Who can change the variant
The client, from their own profile. They'll find a Switch plan button in the membership detail.
The studio, from the admin area. Open the client's membership detail and you'll see the same Switch plan button. Unlike the client, you also see archived and hidden variants in the list, so you can move a client onto a variant that's no longer in the public offer.
Four kinds of switch — each behaves differently
What a switch does depends on what kind of change it is. There are four scenarios:
Kind of switch | Example | What happens today |
Upgrade (same interval, higher price) | Monthly Standard €60 → Monthly Premium €90 | The client is charged the prorated difference for the remaining days, right away. The billing cycle doesn't change. |
Scheduled downgrade (same interval, lower price) | Monthly Premium €90 → Monthly Standard €60 | Nothing is charged today. The change applies automatically at the next regular renewal. The client keeps paying the old price until the end of the current period. |
Interval change (different period length) | Monthly €90 → Yearly €900 | The cycle restarts, Stripe charges the full price of the new period immediately, and a new cycle starts today. |
Same price (different variant, same amount) | Monthly "Pro v1" €75 → Monthly "Pro v2" €75 | The switch happens immediately with no payment. The cycle stays the same. |
Details below.
When a switch is possible
The current membership must be Active (rarely also Awaiting start, though in the current version this practically never applies to recurring memberships — those start as soon as they're paid for; this status mostly applies to one-time memberships).
The membership must not be in the process of being cancelled. If the client has clicked "Cancel at the end of the period", they first need to reverse that (click Keep membership) before they can switch.
The membership must not be paused, unpaid, or in the "Waiting for payment" state (an unfinished 3D Secure verification).
At least 24 hours must pass between variant switches. The clock starts from the last switch made by the client or the studio — and simply scheduling a change counts too (Scenario B). If a client tries sooner, they'll see "You can only switch the plan once every 24 hours. Please try again later." Watch out for a common misunderstanding: cancelling a scheduled change is not time-limited (you can cancel it whenever you like), but a new switch afterwards is only possible 24 hours after the last switch — and the original scheduling counts toward that. On the other hand, the automatic application of a scheduled downgrade at renewal practically never gets in the way, because the scheduling is usually more than 24 hours old by then.
The target variant must be in the same group. You can't switch between groups — to move a client to a different group, they need to cancel the current membership and buy a new one.
The target variant must use the same currency as the current one. If the target variant is in a different currency (variants in the same group usually share a currency, but in rare cases they may differ), Zenamu rejects the switch with "This membership can't be changed in its current state. Variant changes are only possible for active memberships." The reason is technical: the currency of an existing recurring membership can't be changed. The only way around it is to cancel the old membership and buy a new one in the target currency.
Each scenario in detail
Scenario A — Upgrade (same interval, higher price)
Example: A client pays €60/month for "Standard" and is 15 days into a 30-day period. They switch to "Premium" at €90/month.
What happens:
Stripe creates an invoice with two line items: a credit for the unused part of Standard (−€30 for 15 days out of €60) and the prorated amount for 15 days of Premium (+€45 out of €90). Net amount due: €15.
Stripe charges the €15 immediately to the client's card. No credit balance is left on the client's account — the credit is used up directly within this invoice.
The billing cycle does NOT change. The next regular payment (the full €90) goes through on the original date, following the original schedule rather than a month after the switch.
During the switch, the client sees the whole breakdown: the current variant, the new variant, the prorated difference due today, and the date of the next regular payment.
Why only the prorated difference and not the full new price? The client has already paid for the current period, so there's no reason to charge the new price all over again. The cycle simply continues on its original date — the client doesn't feel like they've "restarted" the period and have to pay the full amount again straight away.
What if the payment can't be taken right away? If the client's bank declines it (insufficient funds, expired card, 3D Secure required), Stripe doesn't confirm the payment and the switch doesn't go through. The client sees a generic error saying the payment couldn't be completed — without the specific reason from the bank. You can look up the reason in the Stripe Dashboard (on the relevant invoice or subscription). The client then needs to fix their card (via Manage payment method in their profile — see How a client buys a recurring membership) and start the switch again. This strictness is intentional: if Zenamu changed the variant but Stripe didn't confirm the payment, the billing would end up in a mess. (Stripe is set up so that it reverses the whole change itself when a payment isn't confirmed.)
Scenario B — Scheduled downgrade (same interval, lower price)
Example: A client pays €90/month for "Premium" and is 15 days into a 30-day period. They switch to "Standard" at €60/month.
What happens:
Nothing is charged right away. No payment today, no credit.
The client keeps paying €90 for the remaining 15 days of the current period (already paid for, still using Premium).
On the next renewal date, Zenamu automatically switches the variant to Standard and Stripe charges €60 (not €90).
Both the client and the studio see a notice about the scheduled change in the membership detail, along with the date it takes effect.
The client can cancel the scheduled change (see below) before that date and go back to Premium.
Why no credit? The client has paid the full (higher) price for the current period, so they've got something to use up. Rather than have Stripe return the difference as a credit that would then have to be applied over the following months, it simply waits until the next renewal and charges the new (lower) price. It's clearer for the client that way.
Scenario C — Changing the billing interval
Example: A client pays €90 per month and is 15 days into a 30-day period. They switch to the yearly variant at €900.
What happens:
Stripe restarts the billing cycle as of today.
It creates a single invoice for €900 (the yearly rate) minus a prorated credit for the unused 15 days of the original month (roughly −€45). The client is actually charged about €855 (the net amount). If the new amount is higher than the credit for the unused remainder of the old period, the credit is applied directly to this invoice — no balance is left. If the credit is higher instead (typically when switching from yearly to monthly), the leftover credit stays on the client's account and is applied at future renewals (see the next paragraph).
The client keeps paying yearly from now on; the next renewal is a year from today.
The same principle applies the other way around (yearly → monthly): the cycle restarts, and the net invoice equals the new price minus the prorated credit for the unused part of the previous interval. If the client switches soon after a yearly payment, the credit can be sizeable — not necessarily "small".
Why the cycle restarts in this case: The client explicitly wanted a different interval (for example, moving to yearly for a better price). Restarting the cycle is in line with what the client expects.
Same limitation as with an upgrade: If the client's bank declines the payment or requires 3D Secure, the switch doesn't go through. The client updates their card first, then confirms the change again.
Scenario D — Same price, different variant
Example: A client pays €75/month for "Pro v1" and switches to "Pro v2" at the same €75/month.
What happens:
The variant switches immediately.
No payment, no credit.
The cycle stays the same: the next payment is on the same date, for the same amount.
In practice this is only used occasionally, for example after renaming a variant or making a minor cosmetic change.
The breakdown preview before you confirm
Before the client (or the studio) clicks the Switch plan button to confirm (the confirmation inside the dialog), they see an itemised preview in the dialog. What it shows depends on the kind of switch:
Upgrade: "You'll be charged €15 today (the prorated difference). The next regular payment of €90 is on 15 May 2026 (the original date)."
Scheduled downgrade: "Nothing is charged today. The variant changes to Standard on 15 May 2026 (the next payment date). From then on you'll pay €60/month."
Interval change: "You'll be charged €855 today (€900 minus a €45 credit for the unused 15 days). The new yearly cycle starts today — the next payment of €900 is a year from today."
Same price: "The variant switches right away, with no new charge."
If the client has a credit balance (which can arise, for instance, after a refund issued as credit rather than to the card): the preview amount already takes it into account. So if the preview shows "You'll be charged €10 today", the client really does pay €10 — regardless of the fact that a credit was applied "under the hood". The client doesn't see two figures; they only see the final one.
If Stripe can't run the calculation for some reason (a brief outage, say), the client sees "We couldn't load the payment calculation. Try again in a moment — if it keeps happening, contact the provider." and the Switch plan button is disabled. In that case, just wait a moment and try again.
A scheduled change — how it shows in the membership detail
When a scheduled downgrade (Scenario B) is in effect, both the client and the studio see a yellow/orange notice in the membership detail:
Scheduled plan change Your variant will change to Standard on 15 May 2026. Your current variant continues until then.
[Cancel scheduled change]
The Cancel scheduled change button is available to both the client and the studio. Once confirmed, Zenamu reverts everything to its original state — no change is applied, the client stays on the current variant and keeps paying the same price.
In rare cases, this can happen: If someone has manually edited the subscription price directly in the Stripe Dashboard in the meantime, Zenamu detects the mismatch when you cancel the scheduled change. The button declines the action in that case. Open the Stripe Dashboard from the client's profile, check the current subscription price, and reconcile it manually with what the client is supposed to have.
Important — how the 24-hour limit works after you cancel a scheduled change: Cancelling a scheduled change is not time-limited on its own — you can click Cancel scheduled change whenever you like. But a new switch to a different variant is only possible 24 hours after the last switch the client or studio made, and the original scheduling of the change counts toward that. In practice this means: if you schedule a downgrade and then cancel it straight away, you'll still have to wait before you can switch again. After an automatic application at renewal, on the other hand, the limit practically never applies, because the scheduling is usually more than 24 hours old.
What the client and studio see during the switch
In the membership detail, click Switch plan.
A dialog opens with the list of variants in the same group. The current variant is marked "current".
The client or studio picks the target variant. The dialog loads the breakdown preview described above.
Once confirmed (the Switch plan button in the dialog), Zenamu shows "Plan changed." (for the immediate scenarios) or "Plan change scheduled for the next billing period." (for a scheduled downgrade).
After the switch
The client keeps using the membership without interruption — there's no gap in their access to bookings.
Booking limits belong to the group, not the variant. If the group is set to max 4 bookings per week, that applies regardless of the variant.
Zenamu records the switch internally as a Plan switched event (the label you'll see in the client's activity and in Stripe). With a scheduled downgrade, two such records build up over time (both labelled Plan switched): one when you schedule the change, and one at the next renewal when the downgrade actually takes effect.
The membership status updates automatically in the app for both the client and the admin area — there's no need to refresh the page.
Special cases
What if the group has only one variant?
The Switch plan button doesn't appear — not for the client and not for you. There's nothing to switch between. If you want to let the client switch, add at least one more variant to the group.
The studio switches a client to an archived or hidden variant
In the admin area, the variant list also shows the ones marked Hidden from public or Archived. You can switch a client onto them — for example, when you want to move them to an older variant that keeps its price. The client can't see such a variant themselves; only you can.
What if you add a new variant to the group?
Existing clients will see the new variant in the list when they click Switch plan. They can switch at any time — they don't need anything else from you.
What if you hide or archive an old variant?
Existing clients stay on it until they switch themselves (or until you move them). From their point of view nothing changes — they keep paying the original price. Hiding or archiving only affects new purchases: new prospects won't see the variant.
Watch out — what if a client has a scheduled downgrade and you archive the variant in the meantime: Archiving has no effect on a scheduled change that's already in progress. From the moment it was scheduled, Stripe has the new (lower) price stored and will charge the client exactly that amount at the next renewal. After a successful renewal, Zenamu moves the client onto the archived variant locally too (you'll see the "archived" variant in their membership detail) and records the move internally.
If you want to stop the downgrade from taking effect, you have to explicitly cancel the scheduled change for each such client before the next renewal (the Cancel scheduled change button in the membership detail). Archiving a variant isn't an "off switch" — its only purpose is to stop new clients from buying the variant; it has no retroactive effect on scheduled changes already in progress.
What if the client has a credit balance?
Switching variants doesn't create credit balances — a scheduled downgrade (Scenario B) handles things differently (no credit, just the new price from the next renewal). A client can only have a credit balance from:
An interval change (Scenario C) — a small credit for the unused part of the original period.
Manual operations in Stripe (for example, the studio refunded a payment as credit instead of to the card).
If a credit balance exists, it's applied automatically to one of the next transactions. For details, see article 12 — Refunds and disputed payments.
What if a client switches just before the end of the billing period?
With an upgrade, the prorated difference for the remaining days is small (say, €2 for the last 2 days), so the immediate charge is low. The client sees this amount in the dialog before confirming.
With a scheduled downgrade, it doesn't matter — it applies at the next renewal regardless.
For the studio — when to step in
Changing the variant is, in the vast majority of cases, the client's action. From the admin area, it's worth considering in these situations:
A client asks you to switch them to a specific variant (for example, an agreed price reduction).
You're archiving an old variant and want to move clients onto a new one in bulk (although even then, it's better to talk to the client first and let them switch themselves).
A client can't or won't use their profile (a long absence, say) and you're handling their account manually.
Recommendation: Before you switch a client's variant from the admin area, always tell them in advance what will happen — whether we'll charge the prorated difference immediately (an upgrade), schedule the change for the next renewal (a downgrade), or restart the cycle with a full payment (an interval change). The client should know about the charge ahead of time, even though Stripe sends them a confirmation email automatically.
Frequently asked questions
A client keeps switching every day — why won't it work? The 24-hour limit prevents that kind of experimentation. After the last switch made by the client or the studio, 24 hours must pass before another switch is possible. Scheduling a change counts toward this limit too (Scenario B). If a client tries sooner, Zenamu shows "You can only switch the plan once every 24 hours. Please try again later." Note: even if you cancel the scheduled change in the meantime (which isn't time-limited), a new switch still waits 24 hours from the original scheduling. The automatic application at renewal, on the other hand, practically never gets in the way, because the scheduling is usually more than 24 hours old.
Can I create a "bundle" for a client with 3 different variants at once? No — a client can only ever have one active variant in a group. If you want several simultaneous entitlements, create several groups (the client can then have one variant from each group).
A client switched their variant by mistake — they only wanted to compare prices. How do I undo it?
If it was an upgrade: switching back to the original (cheaper) variant falls under Scenario B — scheduled downgrade. The client has to wait 24 hours and start the switch back; the change then applies only at the next renewal date (they pay the higher price until then). There's no immediate refund.
If it was an interval change: switching back falls under Scenario C — interval change again (the cycle restarts, Stripe works out the prorated adjustment). The client can do this after the 24-hour limit.
If it was a scheduled downgrade: the client can immediately click Cancel scheduled change in the membership detail and go back to the original state. No waiting, no payment.
A client tells me Stripe charged them the full amount after a variant change — is that right? No, unless it was an interval change. With an upgrade (same interval, higher price), only the prorated difference for the remaining days should be charged, not the full new price. If the client reports anything else, check the specific invoice in the Stripe Dashboard from their profile — you'll see the exact breakdown of line items (credit for the unused days + the new prorated amount). Stripe only charges the full new price for an interval change.
When exactly does a scheduled downgrade take effect? On the next renewal date according to the current cycle. If a client's cycle is on the 15th of the month and they scheduled a downgrade on 5 May, the change applies on 15 May (the following renewal). They can see the date in the notice in the membership detail.
Can I schedule a downgrade for any future date I like? No — a scheduled downgrade always takes effect on the date of the next regular renewal. You can't set a date of your own.
Related articles
Managing existing members — all the other actions you can take on a membership
Changing the price for existing members — when you want to change the price of a whole variant, rather than switch one particular client
Discount codes and recurring memberships — discounts aren't reapplied when a variant is switched
When a payment fails — what happens if a payment fails at a scheduled renewal