Chaque abonnement récurrent dans Zenamu conserve un enregistrement interne complet de chaque événement important : du moment de sa création, en passant par chaque renouvellement, pause et annulation, jusqu'à tout remboursement. Cet enregistrement est votre historique complet et votre filet de sécurité pour résoudre les litiges et gérer la comptabilité. Cet article explique où trouver l'activité d'un abonnement et comment lire chaque type d'événement.

Où trouver l'activité d'un abonnement

Ouvrez le détail de l'abonnement d'un client dans l'admin et vous verrez :

Le statut actuel de l'abonnement (actif, suspendu, en attente de paiement, annulé, et ainsi de suite), la prochaine date de renouvellement et — si quelque chose a échoué — des détails sur le délai de grâce et le paiement échoué.
La section Commandes : une liste des documents émis pour cet abonnement (date de création, date de paiement, statut du paiement, montant, description et un lien vers le détail du document). C'est votre principale source d'information sur les paiements réussis individuels, et elle sert aussi de base à votre comptabilité.

Dans son profil (sous Mes abonnements achetés → détail), le client voit le même statut et la même liste de ses commandes.

Important : Zenamu n'a pas encore d'écran « Historique des renouvellements » dédié qui détaille les événements individuels comme les pauses, les changements de variante ou les corrections. Ces événements sont stockés dans un enregistrement interne dans la base de données et reflétés dans votre tableau de bord Stripe (sous Subscriptions, Invoices et Events). Dans l'application, vous avez trois endroits avec lesquels travailler directement : le statut actuel de l'abonnement, la liste des documents (Commandes), et l'activité du client, où les principaux événements sont décrits en langage clair (renouvelé, paiement échoué, mis en pause ou automatiquement mis en pause, repris, annulé par le client, annulé du côté de Stripe ou à la fin de la période). Pour la séquence détaillée de chaque événement individuel, regardez dans Stripe. Ci-dessous, nous décrivons les types d'événements que le système enregistre, afin qu'ils aient du sens quand vous irez les chercher.

Les types d'événements que le système enregistre

Chaque événement interne a un type, une date, et souvent quelques détails supplémentaires (un montant, une raison, l'ID de l'enregistrement associé dans Stripe).

Abonnement créé (premier achat)

Le premier achat réussi d'un abonnement apparaît comme la création de l'abonnement (statut actif, ou brièvement en attente de paiement) et comme le premier document de la section Commandes. Vous pouvez y voir la date, la variante que le client a choisie et le premier montant prélevé.

Renouvellement réussi

Le système enregistre chaque prélèvement récurrent réussi. Un renouvellement comprend :

La date et l'heure du renouvellement.
Le montant prélevé.
La période de facturation que le paiement couvre (vous pouvez la retrouver sur la facture dans Stripe).
Le document émis (un reçu ou une facture), que vous trouverez dans la section Commandes.

Si le client utilise un crédit (qui peut venir, par exemple, d'un remboursement antérieur effectué sous forme de crédit plutôt que sur la carte) et qu'il couvre la totalité du paiement de la période, le renouvellement passe quand même — Zenamu l'enregistre en interne et l'abonnement continue — mais aucun document comptable n'est créé pour lui. Rien n'a été prélevé sur la carte, il n'y a donc rien à documenter. Vous ne trouverez aucun document pour cette période dans la section Commandes ni dans l'export pour votre comptable. Le crédit du client est réduit du prix de la période.

Renouvellement échoué

Le système enregistre chaque tentative de prélèvement par Stripe qui n'a pas abouti (les relances automatiques de Stripe, une relance manuelle, et ainsi de suite).

La date et l'heure de la tentative.
La raison de l'échec (le code de la banque — fonds insuffisants, refusé, carte expirée, vérification requise, et ainsi de suite).

Un seul renouvellement échoué peut générer plusieurs enregistrements (Stripe effectue plusieurs tentatives pendant le délai de grâce). Le meilleur endroit pour retrouver ces tentatives et leurs codes est la facture dans votre tableau de bord Stripe.

Le début du délai de grâce est un événement interne distinct ; en plus, la date de fin du délai de grâce (généralement 7 jours après l'échec) apparaît directement dans l'admin, dans l'avertissement de paiement échoué sur l'abonnement.

Abonnement mis en pause

Cela est enregistré chaque fois qu'un abonnement est mis en pause. Vous pouvez voir qu'un abonnement est en pause directement à son statut dans l'admin. Il y a deux cas :

Pause automatique (parce que la formule du studio a été rétrogradée). Une note explicative décrivant cette raison est enregistrée avec l'événement.
Pause manuelle (depuis l'admin). Elle est enregistrée sans note — aucune raison n'est saisie.

L'activité du client distingue aussi si l'abonnement a été mis en pause (manuellement) ou a été automatiquement mis en pause. Cette différence est importante, car elle détermine si l'abonnement se renouvelle automatiquement quand vous repassez plus tard à la formule Ultimate (seuls les abonnements automatiquement mis en pause le font).

Abonnement repris

Cela est enregistré quand un abonnement en pause est redémarré. La raison distingue s'il s'agissait de :

« Repris automatiquement : le studio est repassé à Ultimate » — automatiquement, après que le studio est revenu à la formule Ultimate.
Une reprise manuelle depuis l'admin ou depuis le profil du client.

Changement de variante

Créé quand un client passe d'une variante à une autre. Dans l'activité du client, l'application intitule cet événement Variante changée.

La date.
Ancienne variante → nouvelle variante.
Le type de changement — une hausse de prix, une baisse de prix programmée, un changement d'intervalle de facturation, ou le même prix (la variante a été renommée, et ainsi de suite).
Selon le scénario : pour une hausse de prix, une facture immédiate apparaît pour la différence au prorata des jours restants (la prochaine date de renouvellement reste la même) ; pour une baisse de prix programmée, aucun document n'est créé le jour où vous changez — l'admin affiche une bannière « Changement programmé à partir du {{date}} » sur l'abonnement, et le changement ne s'applique qu'au prochain renouvellement ; pour un changement d'intervalle de facturation, le cycle redémarre et une seule facture nette est créée (le nouveau prix moins un crédit au prorata pour la partie non utilisée de la période précédente).

Vous pouvez voir qui a effectué le changement depuis l'activité du client dans l'admin. Elle distingue si le client a changé de variante depuis son profil ou si le studio l'a fait depuis l'admin (pour les actions du studio, le nom du membre du personnel est aussi enregistré).

Changement de variante programmé annulé

Quand un client (ou le studio en son nom) annule un changement de variante programmé précédemment défini (toujours le Scénario B — une baisse de prix), la bannière de changement programmé disparaît de l'admin et le système prend une note interne de l'annulation. Il n'y a aucune conséquence financière ; l'abonnement revient simplement à sa variante d'origine sans laisser de trace.

Situations rares autour d'un changement de variante programmé

Il arrive parfois qu'un client programme une baisse de prix, mais que quelque chose d'inhabituel se produise entre la programmation et le jour du renouvellement — par exemple, le studio archive la variante cible entre-temps, ou supprime le groupe. Zenamu gère ces situations automatiquement et en prend une note interne.

Ce qui peut se produire et ce que Zenamu fait :

Ce qui s'est passé	Ce que Zenamu fait
Le studio a archivé la variante cible avant le renouvellement	Le changement n'est pas appliqué. Le prix revient à la variante d'origine, et le client continue comme s'il n'avait jamais programmé la baisse.
Le studio a supprimé entièrement la variante cible	Même comportement que l'archivage.
Le studio a archivé ou supprimé tout le groupe	Même comportement ; le client reste sur la variante d'origine.
Le retour au prix d'origine ne réussit pas techniquement (par ex. une brève panne de Stripe)	Zenamu prend note de la situation. Vous verrez un statut d'avertissement sur l'abonnement dans l'admin. Dans ce cas rare, vous pouvez vérifier le prix actuel de l'abonnement du client dans votre tableau de bord Stripe et l'ajuster manuellement si nécessaire.

Ces situations sont très rares (généralement moins de 1 % des changements programmés). Dans la grande majorité des cas, le changement s'applique exactement comme le client l'avait prévu le jour où il l'a programmé.

Prix mis à jour

Le système enregistre quand le studio a appliqué un changement de prix en masse à ce client. L'enregistrement porte :

La date.
L'ancien et le nouveau prix.
Une note indiquant que le nouveau prix ne s'applique qu'au prochain renouvellement régulier.

Abonnement annulé

Cela est enregistré à chaque annulation — manuelle (le client depuis son profil, le studio depuis l'admin, ou via le portail client Stripe) et automatique (par Zenamu après l'expiration du délai de grâce de 7 jours). Vous pouvez voir qu'un abonnement est annulé directement à son statut dans l'admin (ou une bannière « Annulation à la fin de la période » avec une date). En plus, l'enregistrement interne porte :

La date de l'annulation.
La méthode d'annulation : soit à la fin de la période en cours, soit immédiatement.
La raison de l'annulation (par exemple, une annulation manuelle à la fin de la période, une annulation immédiate, ou une annulation automatique après l'expiration du délai de grâce). Cette description sert uniquement de repère : elle est stockée en interne en anglais et n'est pas le texte exact que vous verriez dans l'application.

Vous pouvez voir qui a effectué l'annulation. À la fois depuis l'enregistrement interne et depuis l'activité du client dans l'admin, vous pouvez savoir si c'est le client, le studio ou le système qui a annulé l'abonnement après l'expiration du délai de grâce. Pour les actions effectuées par le studio, le nom du membre du personnel est aussi enregistré. Ce que l'enregistrement n'inclut pas, c'est un lien vers un éventuel remboursement. Vous le trouverez dans votre tableau de bord Stripe sous Refunds.

Confirmation de paiement requise, et remboursements — ils apparaissent différemment

La confirmation de paiement requise (3D Secure) lors d'un renouvellement est enregistrée comme un événement interne, mais le statut de l'abonnement reste Actif. Quand une vérification supplémentaire est nécessaire lors d'un renouvellement, Zenamu ne le bascule pas sur En attente de paiement (ce statut est réservé à un premier achat non finalisé ; voir l'article « Statuts d'un abonnement »). Le résultat apparaît ensuite soit comme un renouvellement échoué (si le client ne termine pas la vérification et que Stripe arrête d'essayer), soit comme un renouvellement réussi (s'il la termine à temps).

Les remboursements ne sont pas journalisés comme une activité distincte de l'abonnement. Un remboursement total entraîne l'annulation automatique de l'abonnement ; un remboursement partiel ne change pas le statut de l'abonnement. Vous trouverez le statut du remboursement lui-même sur le document (la section Commandes) ou dans votre tableau de bord Stripe.

Correction issue d'une vérification interne (événements rares)

Ce type d'enregistrement journalise une situation où une vérification interne dans Zenamu a trouvé un écart entre son propre état et l'état dans Stripe et l'a soit corrigé, soit noté pour le traiter plus tard. Les types précis sont :

Commande d'achat en attente — le client a acheté, Stripe l'a confirmé, mais Zenamu n'a pas pu créer la commande interne. Le système marque l'enregistrement pour rattrapage ultérieur.
Commande de renouvellement en attente — la même chose, pour un renouvellement.
Remboursement en attente après une concurrence — Zenamu a annulé un abonnement au moment précis où Stripe prélevait un paiement en parallèle. Le remboursement automatique ne s'est pas fait tout de suite, mais il est noté pour être traité plus tard.
Changement de variante en attente — un changement de variante ne s'est pas terminé proprement à un stade donné.
Message pour un abonnement qui n'existe plus — Stripe a envoyé un message à propos d'un abonnement qui n'existe plus dans Zenamu (le client a été supprimé).

Ce sont à peu près les cinq plus fréquents ; Zenamu utilise plusieurs autres marqueurs spécifiques pour des concurrences rares (quand deux choses se produisent au même moment). Ces corrections s'exécutent en arrière-plan ; une correction individuelle ne pose généralement pas de problème en soi — le problème, c'est le même marqueur qui se répète sur le même abonnement. Si vous êtes confronté à une situation de ce genre, contactez le support.

Ces corrections sont informatives et se traduisent par le fait que le statut de l'abonnement dans Zenamu finit par correspondre à Stripe :

Une correction ponctuelle ne pose pas de problème. De petits écarts entre Stripe et Zenamu surviennent de temps à autre.
Un écart répété pour le même client ou studio peut signaler un problème plus profond. Dans votre tableau de bord Stripe, vérifiez si votre compte est restreint (sous Account requirements) et si tous les abonnements récents de ce client correspondent à ce que vous voyez dans Zenamu. Si l'écart persiste, vous pouvez resynchroniser manuellement dans Stripe (annuler et créer un nouvel abonnement).

Mises à jour du statut en temps réel

Dans l'admin, le statut de l'abonnement et la liste des commandes se mettent à jour automatiquement, en temps réel. Cela signifie :

Quand Stripe envoie un message à Zenamu (un paiement réussi, un échec, une annulation), Zenamu bascule le statut de l'abonnement en quelques secondes et ajoute tout nouveau document.
Le studio voit le changement sans avoir à actualiser la page.

Un client, dans son profil, voit le statut actuel seulement après avoir actualisé la page. L'interface du client n'utilise généralement pas les mises à jour en temps réel. Si un client contacte le studio en demandant pourquoi il ne voit pas un nouveau paiement, suggérez-lui d'actualiser la page. Dans certaines situations (juste après un paiement), le navigateur du client vérifie brièvement le statut en arrière-plan, mais en règle générale : actualiser la page = statut actuel.

Dans la plupart des cas, les deux parties verront les changements en quelques secondes à une minute après l'événement réel du côté de Stripe.

Comment utiliser l'activité d'un abonnement en pratique

La combinaison du statut de l'abonnement + de la liste des commandes dans Zenamu et de votre tableau de bord Stripe est utile dans plusieurs situations :

Expliquer un paiement précis à un client

Quand un client écrit « Pourquoi ai-je été prélevé de 60 € le 14 avril ? », ouvrez la section Commandes de son abonnement et vous verrez :

La date et le statut du paiement.
Le montant.
Un lien vers le détail du document (le reçu). Vous pouvez retrouver la période de facturation que le paiement couvre sur la facture dans Stripe.

Vous pouvez ensuite répondre au client avec les détails exacts.

Comprendre pourquoi un abonnement a été annulé

Vous pouvez constater qu'un abonnement a pris fin automatiquement après des paiements échoués à son statut actuel (annulé / non payé) et à l'absence de paiement réussi dans les Commandes. Pour la chronologie des tentatives individuelles et la date de fin du délai de grâce (généralement 7 jours), regardez l'abonnement et les factures concernés dans votre tableau de bord Stripe. Le client sait alors qu'il avait un délai de grâce de 7 jours qu'il n'a pas utilisé.

Rembourser un client pour une période non utilisée

Dans la liste des commandes, vous pouvez voir la date du dernier paiement réussi ; vous pouvez voir jusqu'à quand l'abonnement est valable depuis le statut de l'abonnement (la prochaine date de renouvellement). Calculez le montant au prorata pour les jours non utilisés et émettez le remboursement dans votre tableau de bord Stripe.

Retrouver des prélèvements en double

Si un client affirme que Stripe l'a prélevé deux fois, ouvrez la section Commandes (et, par sécurité, les factures dans Stripe aussi). Vous verrez soit un seul paiement (et le client se trompe), soit deux, auquel cas vous pouvez en rembourser un.

Justificatifs pour la comptabilité

La liste des commandes correspond exactement à votre tableau de bord Stripe. Si votre comptable a besoin d'un justificatif d'un paiement précis, ouvrez le détail du document (et dans Stripe vous trouverez la facturation complète, l'échéance et les détails fiscaux).

Questions fréquentes

Un client me dit qu'il ne voit pas son dernier paiement dans son profil. Quelques possibilités :

Un crédit a couvert la totalité du paiement (aucun mouvement d'argent = aucun document, voir ci-dessus).
Le profil du client ne se met pas à jour en temps réel — demandez-lui d'essayer d'actualiser la page.
Le message de Stripe a été retardé ; patientez une minute et actualisez la page.

Puis-je exporter l'activité d'un abonnement ? Pour la comptabilité, utilisez l'export de documents standard dans l'admin (ISDOC ou Pohoda XML). Il contient toutes les factures et annulations dont votre comptable a besoin. Vous ne trouverez pas de séquence détaillée des événements individuels (renouvellements réussis et échoués, pauses, changements de variante) sous forme de rapport distinct dans l'application ; ces données vivent dans la base de données et dans votre tableau de bord Stripe. Dans la plupart des cas, votre comptable n'en a pas besoin — il travaille avec les documents.

Puis-je supprimer un enregistrement d'événement ? Non. Les enregistrements comptables et historiques ne sont ni supprimés ni réécrits après coup ; on ne fait qu'en ajouter de nouveaux à côté. La raison : l'historique doit rester complet, à la fois à des fins comptables et pour résoudre les litiges.

Que faire si je vois dans Stripe ou dans le statut de l'abonnement quelque chose d'inattendu (par exemple, le résultat d'une correction issue d'une vérification interne) ? Il peut s'agir d'une situation où une vérification interne dans Zenamu a trouvé un écart entre son propre état et l'état dans Stripe et l'a corrigé. Si c'est ponctuel, ce n'est pas un problème (de temps en temps, un message de Stripe se perd, et le filet de sécurité interne corrige le tir). Si l'écart persiste pour le même client, vérifiez le statut de son abonnement dans votre tableau de bord Stripe et comparez-le avec ce que vous voyez dans Zenamu. Si cela ne correspond vraiment pas, contactez le support, ou resynchronisez manuellement dans Stripe (annulez et créez un nouvel abonnement).

Historique des renouvellements et activité de l'abonnement