Every recurring membership in Zenamu keeps a complete internal record of every important event: from the moment it's created, through each renewal, pause, and cancellation, all the way to any refunds. This record is your full history and your safety net for resolving disputes and handling accounting. This article explains where to find a membership's activity and how to read each type of event.
Where to find a membership's activity
Open a client's membership detail in the admin and you'll see:
The membership's current status (active, paused, waiting for payment, cancelled, and so on), the next renewal date, and — if something failed — details about the grace period and the failed payment.
The Orders section: a list of the documents issued for this membership (date created, date paid, payment status, amount, description, and a link to the document detail). This is your main source of information about individual successful payments, and it doubles as the basis for your accounting.
In their profile (under My memberships → detail), the client sees the same status and the same list of their orders.
Important: Zenamu doesn't yet have a dedicated "Renewal history" screen that spells out individual events such as pauses, variant changes, or corrections. Those events are stored in an internal record in the database and mirrored in your Stripe Dashboard (under Subscriptions, Invoices, and Events). In the app you have three places to work with directly: the membership's current status, the list of documents (Orders), and the client's activity, where the main events are described in plain language (renewed, payment failed, paused or automatically paused, resumed, cancelled by the client, cancelled on Stripe's side or at the end of the period). For the detailed sequence of every individual event, look in Stripe. Below we describe the types of events the system records, so they make sense when you go looking for them.
The types of events the system records
Every internal event has a type, a date, and often some extra details (an amount, a reason, the ID of the related record in Stripe).
Membership created (first purchase)
The first successful purchase of a membership shows up as the membership being created (status active, or briefly waiting for payment) and as the first document in the Orders section. From it you can see the date, the variant the client chose, and the first amount charged.
Successful renewal
The system records every successful recurring charge. A renewal includes:
The date and time of the renewal.
The amount charged.
The billing period the payment covers (you can trace this on the invoice in Stripe).
The document issued (a receipt or an invoice), which you'll find in the Orders section.
If the client uses a credit balance (which can come, for example, from an earlier refund issued as credit rather than back to the card) and it covers the full payment for the period, the renewal still goes through — Zenamu records it internally and the membership continues — but no accounting document is created for it. Nothing was charged to the card, so there's nothing to document. You won't find a document for that period in the Orders section or in the export for your accountant. The client's credit is reduced by the price of the period.
Failed renewal
The system records every attempt by Stripe to take a payment that didn't succeed (Stripe's automatic retries, a manual retry, and so on).
The date and time of the attempt.
The reason for the failure (the code from the bank — insufficient funds, declined, expired card, verification required, and so on).
A single failed renewal can generate several records (Stripe makes a number of attempts during the grace period). The best place to trace these attempts and their codes is on the invoice in your Stripe Dashboard.
The start of the grace period is a separate internal event; on top of that, the date the grace period ends (typically 7 days after the failure) appears directly in the admin, as part of the failed-payment warning on the membership.
Membership paused
This is recorded whenever a membership is paused. You can see that a membership is paused directly from its status in the admin. There are two cases:
Automatic pause (because the studio's plan was downgraded). An explanatory note describing this reason is saved with the record.
Manual pause (from the admin). This is saved without a note — no reason is entered.
The client's activity also distinguishes whether the membership was paused (manually) or was automatically paused. This difference is important, because it determines whether the membership renews automatically when you later return to the Ultimate plan (only automatically paused memberships do).
Membership resumed
This is recorded when a paused membership is restarted. The reason distinguishes whether it was:
"Resumed automatically: the studio switched back to Ultimate" — automatically, after the studio returned to the Ultimate plan.
A manual resume from the admin or from the client's profile.
Variant change
Created when a client is switched from one variant to another. In the client's activity, the app labels this event Plan switched.
The date.
Old variant → new variant.
The type of change — a price increase, a scheduled price decrease, a change of billing interval, or the same price (the variant was renamed, and so on).
Depending on the scenario: for a price increase, an immediate invoice appears for the prorated difference for the remaining days (the next renewal date stays the same); for a scheduled price decrease, no document is created on the day you switch — the admin shows a "Scheduled change from {{date}}" banner on the membership, and the change applies only at the next renewal; for a change of billing interval, the cycle restarts and a single net invoice is created (the new price minus a prorated credit for the unused part of the previous period).
You can see who made the change from the client's activity in the admin. It distinguishes whether the client switched the variant from their profile or the studio did it from the admin (for studio actions, the staff member's name is saved too).
Scheduled variant change cancelled
When a client (or the studio on their behalf) cancels a previously set scheduled variant change (always Scenario B — a price decrease), the scheduled-change banner disappears from the admin and the system makes an internal note of the cancellation. There are no financial consequences; the membership simply reverts to its original variant without a trace.
Rare situations around a scheduled variant change
Occasionally a client schedules a price decrease, but something unusual happens between scheduling it and the renewal day — for example, the studio archives the target variant in the meantime, or deletes the group. Zenamu handles these situations automatically and makes an internal note of them.
What can happen and what Zenamu does:
What happened | What Zenamu does |
The studio archived the target variant before the renewal | The change isn't applied. The price reverts to the original variant, and the client continues as if they'd never scheduled the decrease. |
The studio deleted the target variant entirely | Same behaviour as archiving. |
The studio archived or deleted the whole group | Same behaviour; the client stays on the original variant. |
Reverting the price doesn't succeed technically (e.g. a brief Stripe outage) | Zenamu makes a note of the situation. You'll see a warning status on the membership in the admin. In this rare case, you can check the client's current subscription price in your Stripe Dashboard and adjust it manually if needed. |
These situations are very rare (typically fewer than 1% of scheduled changes). In the vast majority of cases, the change goes through exactly as the client intended on the day they scheduled it.
Price updated
The system records when the studio applied a bulk price change to this client. The record carries:
The date.
The old and new price.
A note that the new price applies only at the next regular renewal.
Membership cancelled
This is recorded on any cancellation — manual (the client from their profile, the studio from the admin, or via the Stripe customer portal) and automatic (by Zenamu after the 7-day grace period expires). You can see that a membership is cancelled directly from its status in the admin (or a "Cancellation at the end of the period" banner with a date). On top of that, the internal record carries:
The date of the cancellation.
The method of cancellation: either at the end of the current period, or immediately.
The reason for the cancellation (for example, a manual cancellation at the end of the period, an immediate cancellation, or an automatic cancellation after the grace period expired). This description is for guidance only: it's stored internally in English and isn't the exact text you'd see in the app.
You can see who made the cancellation. From both the internal record and the client's activity in the admin, you can tell whether the client, the studio, or the system cancelled the membership after the grace period expired. For actions taken by the studio, the staff member's name is saved too. What the record doesn't include is a link to any refund. You'll find that in your Stripe Dashboard under Refunds.
Payment confirmation required, and refunds — these show up differently
Payment confirmation required (3D Secure) on a renewal is recorded as an internal event, but the membership's status stays Active. When extra verification is needed on a renewal, Zenamu does not switch it to Waiting for payment (that status is reserved for an unfinished first purchase; see the article "Membership statuses"). The outcome then shows up either as a failed renewal (if the client doesn't complete the verification and Stripe stops trying) or as a successful renewal (if they complete it in time).
Refunds aren't logged as a separate membership activity. A full refund leads to the membership being cancelled automatically; a partial refund doesn't change the membership's status. You'll find the status of the refund itself on the document (the Orders section) or in your Stripe Dashboard.
Correction from an internal check (rare events)
This type of record logs a situation where an internal check in Zenamu found a discrepancy between its own state and the state in Stripe and either corrected it or made a note of it to handle later. The specific types are:
Pending purchase order — the client bought, Stripe confirmed it, but Zenamu couldn't create the internal order. The system flags the record to catch up later.
Pending renewal order — the same, for a renewal.
Pending refund after a race — Zenamu cancelled a membership at the very moment Stripe took a payment in parallel. The automatic refund didn't happen right away, but it's noted to be handled later.
Pending variant switch — a variant switch didn't finish cleanly at some stage.
Message for a membership that no longer exists — Stripe sent a message about a membership that no longer exists in Zenamu (the client was deleted).
These are roughly the five most common; Zenamu uses several other specific markers for rare races (when two things happen at the same moment). These corrections run in the background; an individual correction is usually fine on its own — the problem is the same marker repeating on the same membership. If you're dealing with a situation like this, contact support.
These corrections are informational and show up in the sense that the membership's status in Zenamu ends up matching Stripe:
A one-off correction is fine. Small mismatches between Stripe and Zenamu happen from time to time.
A repeated mismatch for the same client or studio can point to a deeper problem. In your Stripe Dashboard, check whether your account is restricted (under Account requirements) and whether all recent subscriptions for this client match what you see in Zenamu. If the mismatch persists, you can resync manually in Stripe (cancel and create a new subscription).
Real-time status updates
In the admin, the membership status and the list of orders update automatically, in real time. That means:
When Stripe sends Zenamu a message (a successful payment, a failure, a cancellation), Zenamu switches the membership status within a few seconds and adds any new document.
The studio sees the change without having to refresh the page.
A client, in their profile, sees the current status only after refreshing the page. The client interface generally doesn't use real-time updates. If a client contacts the studio asking why they don't see a new payment, suggest they refresh the page. In some situations (right after a payment), the client's browser briefly checks the status in the background, but as a rule: refresh the page = current status.
In most cases, both sides will see changes within a few seconds to a minute of the actual event on Stripe's side.
How to use a membership's activity in practice
The combination of the membership status + the list of orders in Zenamu and your Stripe Dashboard is useful in several situations:
Explain a specific payment to a client
When a client writes "Why was I charged €60 on April 14?", open the Orders section in their membership and you'll see:
The date and payment status.
The amount.
A link to the document detail (the receipt). You can trace the billing period the payment covers on the invoice in Stripe.
You can then reply to the client with the exact details.
Understand why a membership was cancelled
You can tell that a membership ended automatically after failed payments from its current status (cancelled / unpaid) and from the missing successful payment in Orders. For the timeline of the individual attempts and the date the grace period ended (typically 7 days), look at the relevant subscription and invoices in your Stripe Dashboard. The client then knows they had a 7-day grace period that they didn't use.
Refund a client for an unused period
In the list of orders you can see the date of the last successful payment; you can see how long the membership is valid from the membership status (the next renewal date). Work out the prorated amount for the unused days and issue the refund in your Stripe Dashboard.
Track down duplicate charges
If a client claims Stripe charged them twice, open the Orders section (and, to be safe, the invoices in Stripe too). You'll either see just one payment (and the client is mistaken) or two, in which case you can refund one of them.
Documentation for accounting
The list of orders matches your Stripe Dashboard one to one. If your accountant needs proof of a specific payment, open the document detail (and in Stripe you'll find the full billing, due date, and tax details).
Frequently asked questions
A client tells me they don't see their last payment in their profile. A few possibilities:
A credit covered the full payment (no money moved = no document, see above).
The client's profile doesn't update in real time — ask them to try refreshing the page.
The message from Stripe was delayed; wait a minute and refresh the page.
Can I export a membership's activity? For accounting, use the standard document export in the admin (ISDOC or Pohoda XML). It contains all the invoices and cancellations your accountant needs. You won't find a detailed sequence of individual events (successful and failed renewals, pauses, variant switches) as a separate report in the app; that data lives in the database and in your Stripe Dashboard. In most cases your accountant doesn't need it — they work with the documents.
Can I delete an event record? No. Accounting and historical records aren't deleted or rewritten after the fact; new ones are only added alongside them. The reason: the history has to stay complete, both for accounting purposes and for resolving disputes.
What if I see something I don't expect in Stripe or in the membership status (for example, the result of a correction from an internal check)? It may be a situation where an internal check in Zenamu found a discrepancy between its own state and the state in Stripe and corrected it. If it's a one-off, it's fine (every now and then a message from Stripe gets lost, and the internal safety net puts it right). If the mismatch persists for the same client, check the status of their subscription in your Stripe Dashboard and compare it with what you see in Zenamu. If it really doesn't match, contact support, or resync manually in Stripe (cancel and create a new subscription).
Related articles
Managing existing members — all the actions that generate internal events and change a membership's status
When a payment fails — the details of what happens when a payment fails and the related events
Common problems and how to solve them — how to handle the specific situations these details help you understand