Une action génère souvent plusieurs événements. Par exemple, un premier achat envoie à la fois Subscription started et Access level updated. Les diagrammes ci-dessous montrent ce qu’Adapty envoie lorsqu’un utilisateur s’abonne, annule ou réactive son abonnement, et dans quel ordre.

Comment lire les diagrammes

• Timing. Apple facture un abonnement plusieurs heures avant qu’il commence ou se renouvelle. Afficher cet écart ajouterait une étape à chaque diagramme sans changer les événements que vous recevez, donc les diagrammes placent le prélèvement et le démarrage ensemble.
• Ordre. Les événements d’une même action arrivent au même moment. Un diagramme doit les dessiner dans un certain ordre, mais votre Event Feed peut les lister dans un ordre différent, et aucun des deux n’est plus correct que l’autre.
• Couverture. Une notification du store déclenche chaque événement affiché. Les événements synthétiques n’apparaissent pas : Adapty les envoie selon un minuteur, et le délai varie selon l’intégration, donc ils n’ont pas de place fixe dans une séquence.

Cycle de vie d’un abonnement

Flow d’achat initial

Ce flow se produit lorsqu’un client souscrit un abonnement pour la première fois sans période d’essai. Dans ce cas, les événements suivants sont créés :

• Subscription started
• Access level updated pour accorder l’accès à l’utilisateur

Lorsque la date de renouvellement de l’abonnement arrive, l’abonnement est renouvelé. Dans ce cas, les événements suivants sont créés :

• Subscription renewal pour démarrer une nouvelle période d’abonnement
• Access level updated pour mettre à jour la date d’expiration de l’abonnement, prolongeant l’accès pour une période supplémentaire

Les situations où le paiement échoue ou où l’utilisateur annule le renouvellement sont décrites dans Flux de résultat en cas de problème de facturation et Flux d’annulation d’abonnement, respectivement.

Flux d’annulation d’abonnement

Lorsqu’un utilisateur annule son abonnement, les événements suivants sont créés :

• Subscription renewal canceled pour indiquer que l’abonnement reste actif jusqu’à la fin de la période en cours, après quoi l’utilisateur perdra l’accès
• L’événement Access level updated est créé pour désactiver le renouvellement automatique pour le niveau d’accès

Une fois l’abonnement terminé, l’événement Subscription expired (churned) est déclenché pour marquer la fin de l’abonnement.

Si un remboursement est approuvé, l’événement suivant remplace Subscription expired (churned) :

• Subscription refunded pour mettre fin à l’abonnement et fournir les détails du remboursement

Pour Stripe, un abonnement peut être annulé immédiatement, sans attendre la fin de la période en cours. Dans ce cas, tous les événements sont créés simultanément :

• Subscription renewal cancelled
• Subscription expired (churned)
• Access Level updated pour supprimer l’accès de l’utilisateur

Si un remboursement est approuvé, un événement Subscription refunded est également déclenché au moment de son approbation.

Flux de réactivation d’un abonnement

Si un utilisateur annule un abonnement, que celui-ci expire, et qu’il rachète ensuite le même abonnement, un événement Subscription renewed sera créé. Même s’il y a une interruption d’accès, Adapty considère cela comme une seule chaîne de transactions, liée par le vendor_original_transaction_id. Le rachat est donc traité comme un renouvellement.

Les événements Access level updated seront créés à deux reprises :

• à l’expiration de l’abonnement, pour révoquer l’accès de l’utilisateur
• lors du rachat de l’abonnement, pour accorder à nouveau l’accès

Flux de pause d’abonnement (Android uniquement)

Ce flux s’applique lorsqu’un utilisateur met en pause puis reprend un abonnement sur Android.

La mise en pause d’un abonnement a des effets différés. Si un utilisateur met en pause un abonnement avant son renouvellement, l’abonnement reste actif et l’utilisateur conserve l’accès payant jusqu’à la fin de la période de facturation en cours.

1. Lorsque l’utilisateur met un abonnement en pause, l’événement Subscription paused (Android only) est déclenché.

2. À la fin de la période d’abonnement, Adapty déclenche l’événement Access level updated pour révoquer l’accès de l’utilisateur.

3. Lorsque l’utilisateur reprend l’abonnement, les événements suivants sont déclenchés :

   • Subscription renewed
   • Access level updated pour rétablir l’accès de l’utilisateur

Ces abonnements appartiennent à la même chaîne de transactions, liés par le même vendor_original_transaction_id.

Flows des essais

Si vous utilisez des essais dans votre application, vous recevrez des événements supplémentaires liés aux essais.

Flow d’essai avec conversion réussie

Le flow le plus courant survient lorsqu’un utilisateur démarre un essai, fournit une carte bancaire et se convertit avec succès en abonnement standard à la fin de la période d’essai. Dans cette situation, les événements suivants sont créés au moment du démarrage de l’essai :

• Trial started pour marquer le début de l’essai
• Access level updated pour accorder l’accès

L’événement Trial converted est créé au démarrage de l’abonnement standard.

Flow d’essai sans conversion réussie

Si un utilisateur annule l’essai avant qu’il ne se convertisse en abonnement, les événements suivants sont créés au moment de l’annulation :

• Trial renewal cancelled pour désactiver la conversion automatique de l’essai en abonnement
• Access level updated pour désactiver le renouvellement de l’accès

L’utilisateur conservera l’accès jusqu’à la fin de l’essai, moment auquel l’événement Trial expired est créé pour marquer la fin de l’essai.

Flow de réactivation d’abonnement après expiration d’un essai

Si un essai expire (suite à un problème de facturation ou à une annulation) et que l’utilisateur souscrit ensuite un abonnement, les événements suivants sont créés :

• Access level updated pour accorder l’accès à l’utilisateur
• Trial converted

Même en cas d’interruption entre l’essai et l’abonnement, Adapty relie les deux via vendor_original_transaction_id. Cette conversion est traitée comme faisant partie d’une chaîne de transactions continue, débutant par un essai à prix zéro. C’est pourquoi l’événement Trial converted est créé plutôt que Subscription started.

Modifications de produit

Cette section couvre toutes les modifications apportées aux abonnements actifs, comme les mises à niveau, les rétrogradations ou les achats d’un produit appartenant à un autre groupe.

Flux de changement de produit immédiat

Après qu’un utilisateur change de produit, ce changement peut prendre effet immédiatement dans le système avant la fin de l’abonnement (principalement en cas de mise à niveau ou de remplacement d’un produit). Dans ce cas, au moment du changement de produit :

• Le niveau d’accès est modifié, et deux événements Access level updated sont créés :
  1. pour retirer l’accès au premier produit.
  2. pour accorder l’accès au deuxième produit.
• L’ancien abonnement se termine et un remboursement est effectué (l’événement Subscription refunded est créé avec cancellation_reason = upgraded). Notez qu’aucun événement Subscription expired (churned) n’est créé ; l’événement Subscription refunded le remplace.
• Le nouvel abonnement commence (l’événement Subscription started est créé pour le nouveau produit).

Si un utilisateur rétrograde son abonnement, le premier abonnement restera actif jusqu’à la fin de la période payée, puis sera remplacé par le nouvel abonnement de niveau inférieur. Dans ce cas, seul l’événement Access level updated désactivant le renouvellement automatique de l’accès sera créé immédiatement. Tous les autres événements seront créés au moment du remplacement effectif de l’abonnement :

• Un autre événement Access level updated est créé pour accorder l’accès au second produit.
• L’événement Subscription expired (churned) est créé pour mettre fin à l’abonnement du premier produit.
• L’événement Subscription started est créé pour démarrer un nouvel abonnement pour le nouveau produit.

Flux de changement de produit différé

Il existe également un cas où un utilisateur change de produit au moment du renouvellement de l’abonnement. Ce cas est très similaire au précédent : un événement Access level updated sera créé immédiatement pour désactiver le renouvellement automatique du niveau d’accès de l’ancien produit. Tous les autres événements seront créés au moment où l’utilisateur change d’abonnement et que ce changement est pris en compte dans le système :

• Un autre événement Access level updated est créé pour accorder l’accès au second produit.
• L’événement Subscription expired (churned) est créé pour mettre fin à l’abonnement du premier produit.
• L’événement Subscription started est créé pour démarrer un nouvel abonnement pour le nouveau produit.

Flux de résultat en cas de problème de facturation

Si les tentatives de conversion d’un essai ou de renouvellement d’un abonnement échouent en raison d’un problème de facturation, la suite dépend de l’activation ou non d’un délai de grâce.

Avec un délai de grâce, si le paiement aboutit, l’essai est converti ou l’abonnement est renouvelé. En cas d’échec, le store continue de tenter de débiter l’utilisateur pour l’abonnement, et si cela échoue toujours, le store met fin à l’essai ou à l’abonnement.

Ainsi, au moment du problème de facturation, les événements suivants sont créés dans Adapty :

• Billing issue detected
• Entered grace period (si le délai de grâce est activé)
• Access level updated pour maintenir l’accès jusqu’à la fin du délai de grâce

Si le paiement aboutit par la suite, Adapty enregistre un événement Trial converted ou Subscription renewed, et l’utilisateur ne perd pas son accès.

Si le paiement échoue définitivement et que le store annule l’abonnement, Adapty génère les événements suivants :

• Trial expired ou Subscription expired (churned) avec cancellation_reason: billing_error
• Access level updated pour révoquer l’accès de l’utilisateur

Sans délai de grâce, la période de nouvelle tentative de facturation (pendant laquelle le store tente à nouveau de débiter l’utilisateur) commence immédiatement.

Si le paiement n’aboutit jamais avant la fin du délai de grâce, le déroulement est identique : les mêmes événements sont créés lorsque le store met fin à l’abonnement automatiquement :

• Événement Trial expired ou Subscription expired (churned) avec un cancellation_reason égal à billing_error

• Niveau d’accès mis à jour pour révoquer l’accès de l’utilisateur

Partage des achats entre les flux de comptes utilisateurs

Lorsqu’un Customer User ID iOS, Android, React Native, Flutter, et Unity tente de restaurer ou de prolonger un abonnement déjà associé à un autre Customer User ID iOS, Android, React Native, Flutter, et Unity , le paramètre Sharing paid access between user accounts d’Adapty contrôle la gestion des accès. Le déroulement variera selon l’option sélectionnée.

Pour un aperçu rapide des événements déclenchés lorsqu’un second profil revendique un abonnement existant, utilisez cette matrice. Les sections suivantes présentent le payload JSON complet pour chaque flow.

Événement	Activé (par défaut)	Transférer le niveau d’accès au nouvel utilisateur	Désactivé
Nouveau profil : Access level updated (is_active=true)	Se déclenche	Se déclenche	Ne se déclenche pas
Ancien profil : Access level updated (is_active=false)	Ne se déclenche pas — les deux profils conservent le niveau d’accès	Se déclenche lorsque le nouvel appareil identifié propage la transaction	Ne se déclenche pas — le profil d’origine conserve le niveau d’accès
Champ profiles_sharing_access_level sur le nouvel événement	Liste les autres profils qui partagent le niveau d’accès	null	Non applicable — aucun événement ne se déclenche

Les renouvellements, remboursements et expirations d’un abonnement transféré continuent de déclencher les événements subscription_renewed, subscription_refunded et subscription_expired sur le profil qui détient actuellement le niveau d’accès. Le transfert lui-même n’émet pas d’événement subscription_started, car aucune nouvelle transaction n’est enregistrée — seule l’attribution change.

Pour les détails contractuels par mode, voir Référence pratique.

Transférer le niveau d’accès vers le nouveau profil utilisateur

L’option recommandée est de transférer le niveau d’accès vers le nouvel utilisateur. Cela préserve l’historique des transactions de l’utilisateur d’origine pour une analyse cohérente. Seuls 2 événements Access level updated seront créés :

1. pour supprimer le niveau d’accès du premier utilisateur
2. pour accorder le niveau d’accès au second utilisateur

Voici un détail des champs liés à l’attribution et au transfert du niveau d’accès dans les événements générés dans ce scénario :

• Utilisateur A : Niveau d’accès mis à jour (envoyé lorsque l’utilisateur A achète un abonnement dans l’application)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

• Utilisateur A : Niveau d’accès mis à jour (envoyé lorsque l’application est réinstallée et que l’utilisateur B se connecte, révoquant l’accès de l’utilisateur A)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": false,
    },
    "profiles_sharing_access_level": null
  }

• Utilisateur B : niveau d’accès mis à jour (envoyé lorsque l’utilisateur B se connecte et que l’accès est accordé)

  {
    "profile_id": "00000000-0000-0000-0000-000000000001",
    "customer_user_id": UserB,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

Flux d’accès partagé entre utilisateurs

Cette option permet à plusieurs utilisateurs de partager le même niveau d’accès si leur appareil est connecté au même identifiant Apple/Google. C’est utile lorsqu’un utilisateur réinstalle l’application et se connecte avec une adresse e-mail différente — il conserve quand même l’accès à son achat précédent. Avec cette option, plusieurs utilisateurs identifiés peuvent partager le même niveau d’accès. Pendant que le niveau d’accès est partagé, toutes les transactions sont enregistrées sous le Customer User ID iOS, Android, React Native, Flutter, et Unity d’origine afin de conserver un historique complet des transactions et des analyses.

Par conséquent, un seul événement sera créé : Access level updated pour accorder l’accès au deuxième utilisateur.

Voici un aperçu des champs liés à l’attribution et au partage du niveau d’accès dans les événements générés dans ce scénario :

Utilisateur B : Access level updated (envoyé lorsque l’utilisateur B se connecte et que l’accès est accordé)

{
  "profile_id": "00000000-0000-0000-0000-000000000000",
  "customer_user_id": UserA,
  "event_properties": {
    "profile_has_access_level": true,
  },
  "profiles_sharing_access_level": [
    {
      "profile_id": "00000000-0000-0000-0000-000000000001,
      "customer_user_id": UserB
    }
  ]
}

Le niveau d’accès n’est pas partagé entre les utilisateurs dans le flow

Avec cette option, seul le premier profil utilisateur à recevoir le niveau d’accès le conserve de façon permanente. C’est idéal si les achats doivent être associés à un seul Customer User ID iOS, Android, React Native, Flutter et Unity .