Gestion du cycle de vie de l’abonnement SaaS

La Place de marché commerciale gère tout le cycle de vie d’un abonnement SaaS après son achat par l’utilisateur final. Il utilise la page d’accueil, les API de traitement, les API d’opérations et le webhook comme mécanisme pour piloter l’activation, l’utilisation, les mises à jour et l’annulation de l’abonnement SaaS réels. La facture de l’utilisateur final est basée sur l’état de l’abonnement SaaS que Microsoft gère.

États d’un abonnement SaaS

Le diagramme suivant montre les états d’un abonnement SaaS et les actions applicables.

Acheté mais pas encore activé (PendingFulfillmentStart)

Une fois qu’un utilisateur final ou un fournisseur de solutions cloud (CSP) achète une offre SaaS sur la Place de marché commerciale, l’éditeur est averti de l’achat. L’éditeur peut ensuite créer et configurer un nouveau compte SaaS côté serveur de publication pour l’utilisateur final.

Pour que la création de compte se produise :

1. Le client sélectionne le Configurer le compte maintenant bouton disponible pour une offre SaaS après son achat réussi dans Microsoft AppSource ou le portail Azure. Vous pouvez également utiliser le Configurer maintenant bouton dans l’e-mail qu’il recevra peu après l’achat.
2. Microsoft avertit ensuite le partenaire de l’achat en ouvrant l’URL de la page d’accueil avec le paramètre de jeton (le jeton d’identification d’achat à partir de la Place de marché commerciale) dans le nouvel onglet du navigateur.

Un exemple de tel appel est https://contoso.com/signup?token=<blob>, mais l’URL de la page d’accueil de cette offre SaaS dans l’Espace partenaires est configurée comme https://contoso.com/signup. Ce jeton fournit au serveur de publication un ID qui identifie de manière unique l’achat SaaS et le client.

Pourboire

N’incluez pas le caractère de signe dièse (#) dans l’URL de la page d’accueil. Sinon, les clients ne peuvent pas accéder à votre page d’accueil. L’éditeur a 30 jours pour résoudre la ressource lorsque l’état est PendingFulfillmentStart. Sinon, la ressource est annulée. Étant donné que le cycle de facturation n’a pas été lancé et que l’achat respectif n’est pas facturé, l’état passe ensuite à abonnement. Le client n’est pas facturé pour l’achat.

Important

L’URL de la page d’accueil doit être opérationnelle tous les jours, tous les jours et prête à recevoir de nouveaux appels de Microsoft toujours. Si la page d’accueil devient indisponible, les clients ne peuvent pas s’inscrire au service SaaS et commencer à l’utiliser.

Ensuite, le serveur de publication doit transmettre le jeton à Microsoft en appelant l''API De résolution SaaS, et en entrant le jeton comme valeur du paramètre x-ms-marketplace-token header. À la suite de l’appel d’API Resolve, le jeton est échangé pour plus d’informations sur l’achat SaaS, comme l’ID unique de l’achat, l’ID d’offre acheté et l’ID de plan acheté.

Sur la page d’accueil, le client doit être connecté au compte SaaS nouveau ou existant via l’authentification unique Microsoft Entra.

Note

L’éditeur n’est pas informé de l’achat SaaS tant que le client n’a pas lancé le processus de configuration côté Microsoft.

L’éditeur doit implémenter l’authentification unique pour fournir l’expérience utilisateur requise par Microsoft pour ce flux. Veillez à utiliser l’application Microsoft Entra mutualisée et autorisez les comptes professionnels et scolaires ou les comptes Microsoft personnels lors de la configuration de l’authentification unique. Cette exigence s’applique uniquement à la page d’accueil, pour les utilisateurs qui sont redirigés vers le service SaaS lorsqu’ils sont déjà connectés avec les informations d’identification Microsoft. L’authentification unique n’est pas nécessaire pour toutes les connexions au service SaaS.

Note

Si l’authentification unique exige qu’un administrateur accorde l’autorisation à une application, la description de l’offre dans l’Espace partenaires doit divulguer que l’accès au niveau de l’administrateur est requis. Cette divulgation est conforme aux stratégies de certification de la place de marché commerciale .

Une fois connecté, le client doit terminer la configuration SaaS côté serveur de publication. Ensuite, l’éditeur doit appeler l’API Activer l’abonnement pour envoyer un signal à la Place de marché Azure que l’approvisionnement du compte SaaS est terminé. Cette action démarre le cycle de facturation du client. Si l’appel de l’API Activer l’abonnement n’est pas réussi, le client n’est pas facturé pour l’achat.

L’acheteur et le propriétaire du compte de facturation reçoivent un e-mail lui demandant de configurer le compte.

Note

Le serveur de publication a 30 jours pour résoudre la ressource lorsque l’état est PendingFulfillmentStart. Sinon, l’actif est annulé depuis que le cycle de facturation n’a pas été initié et que l’achat respectif n’est pas facturé. L’état passe à désinscription. Le client n’est pas facturé pour l’achat.

Actif (abonné )

actif (abonné) est l’état stable d’un abonnement SaaS approvisionné. Une fois les processus côté Microsoft terminés, l’API Activer l’abonnement, l’abonnement SaaS est marqué comme abonné. Le client peut désormais utiliser le service SaaS côté éditeur et est facturé.

Lorsqu’un abonnement SaaS est déjà actif, le client peut sélectionner gérer l’expérience SaaS à partir du portail Azure ou du Centre d’administration Microsoft 365. Cette action entraîne également l’appel de l’URL de la page d’accueil avec le paramètre jeton, comme dans le flux d’activation. L’éditeur doit faire la distinction entre les nouveaux achats et la gestion des comptes SaaS existants et gérer cet appel d’URL de page d’accueil en conséquence.

Un e-mail de notification d’activation est envoyé à la fois à l’acheteur et au propriétaire du compte de facturation.

Mise à jour (abonnement)

Cette action signifie qu’une mise à jour vers un abonnement SaaS actif existant est traitée par Microsoft et l’éditeur. Mises à jour lancées par :

• Client de la Place de marché commerciale.
• Fournisseur de solutions Cloud à partir de la Place de marché commerciale.
• Client à partir du site SaaS de l’éditeur (mais pas pour les achats effectués par le fournisseur de solutions Cloud).

Deux types de mises à jour sont disponibles pour un abonnement SaaS :

• Mettre à jour le plan lorsque le client choisit un autre plan pour l’abonnement.
• Mettez à jour la quantité lorsque le client modifie le nombre de licences achetées pour l’abonnement.

Seul un abonnement actif peut être mis à jour. Pendant la mise à jour de l’abonnement, son état reste actif côté Microsoft.

Mise à jour lancée à partir de la Place de marché commerciale

Dans ce flux, le client modifie le plan d’abonnement ou la quantité de licences à partir du portail Azure ou du Centre d’administration Microsoft 365.

1. Une fois qu’une mise à jour est entrée, Microsoft appelle l’URL du webhook de l’éditeur, configurée dans le champ webhook Connexion sur la page de configuration technique page dans l’Espace partenaires, avec une valeur appropriée pour action et d’autres paramètres pertinents.
2. Le côté serveur de publication doit apporter les modifications requises au service SaaS et avertir Microsoft lorsque vous avez terminé d’appeler l’API Mise à jour de l’API d’opération.
3. Si le correctif est envoyé avec échec état, le processus de mise à jour ne se termine pas côté Microsoft. L’abonnement SaaS conserve le plan existant et la quantité de licences.

Note

L’éditeur doit appeler PATCH pour mettre à jour l’état de l’API d’opération avec une réponse d’échec/réussite dans une fenêtre de 10 secondes après réception de la notification webhook. Si PATCH de l’état de l’opération n’est pas reçu dans les 10 secondes, le plan de modification est corrigé automatiquement en tant que Réussite.

La séquence d’appels d’API pour un scénario de mise à jour qui démarre à partir de la Place de marché commerciale est illustrée dans le diagramme suivant.

Mise à jour lancée à partir de l’éditeur

Dans ce flux, le client modifie le plan d’abonnement ou la quantité de licences achetées auprès du service SaaS lui-même.

1. Avant que la modification demandée soit effectuée côté éditeur, le code de l’éditeur doit appeler l’API Change Plan ou l’API Modifier la quantité ou les deux.
2. Microsoft applique la modification à l’abonnement, puis notifie l’éditeur via webhook connexion appliquer la même modification.
3. Seul le serveur de publication doit apporter la modification requise à l’abonnement SaaS et avertir Microsoft lorsque la modification est effectuée en appelant 'état de mise à jour de l’API d’opération.

La séquence d’appels d’API pour un scénario de mise à jour qui démarre du côté éditeur est illustrée dans le diagramme suivant.

Un e-mail de notification indiquant qu’une modification de plan est envoyée à l’acheteur et au propriétaire du compte de facturation.

Un e-mail de notification indiquant qu’une modification de la quantité est envoyée à l’acheteur et au propriétaire du compte de facturation.

Suspendu (suspendu)

Cet état indique que le paiement d’un client pour le service SaaS n’a pas été reçu. Microsoft avertit l’éditeur de cette modification dans l’état de l’abonnement SaaS. La notification est effectuée via un appel au webhook avec l’action paramètre défini sur suspendu.

L’éditeur peut ou non apporter des modifications au service SaaS côté éditeur. Nous vous recommandons de rendre ces informations accessibles au client suspendu et de limiter ou de bloquer l’accès du client au service SaaS. Il y a une probabilité que le paiement ne soit jamais reçu.

Note

Microsoft donne au client une période de grâce de 30 jours avant d’annuler automatiquement l’abonnement. Une fois la période de grâce de 30 jours terminée, le webhook reçoit une action de Unsubscribe.

Lorsqu’un abonnement est à l’état suspendu :

• Le partenaire ou l’éditeur de logiciels indépendants doit conserver le compte SaaS dans un état récupérable, afin que les fonctionnalités complètes puissent être restaurées sans aucune perte de données ou de paramètres.
• Le partenaire ou l’ÉDITEUR de logiciels indépendants doit s’attendre à une demande de rétablissement de l’abonnement, si le paiement est reçu pendant la période de grâce ou une demande de déprovisionnement de l’abonnement à la fin de la période de grâce. Le mécanisme de webhook envoie les deux requêtes.

L’état de l’abonnement est remplacé par suspendu côté Microsoft avant que l’éditeur n’effectue une action. Seuls les abonnements actifs peuvent être suspendus.

Un e-mail de notification indiquant le changement d’état à suspendu est envoyé à la fois à l’acheteur et au propriétaire du compte de facturation.

Après une période de suspension de 30 jours, un e-mail concernant l’annulation post-suspension est envoyé à l’acheteur et au propriétaire du compte de facturation.

Rétabli (suspendu)

Cette action indique que l’instrument de paiement du client est à nouveau valide. Un paiement a été effectué pour l’abonnement SaaS et l’abonnement est rétabli. Dans ce cas :

1. Microsoft appelle le webhook avec une action paramètre défini sur la valeur de rétablie.
2. L’éditeur s’assure que l’abonnement est entièrement opérationnel côté éditeur.
3. Le processus de rétablissement réussit et le client est à nouveau facturé pour l’abonnement SaaS.

Seul un abonnement suspendu peut être rétabli. L’abonnement SaaS suspendu reste dans un état de suspendu pendant qu’il est rétabli. Une fois cette opération terminée, l’état de l’abonnement devient actif.

Un e-mail est envoyé à la fois à l’acheteur et au propriétaire de facturation après la transition de l’état suspendu à l’état rétabli.

Renouvelé (abonné )

Microsoft renouvelle automatiquement l’abonnement SaaS à la fin de la période d’abonnement d’un mois ou d’un an. La valeur par défaut du paramètre de récupération automatique est true pour tous les abonnements SaaS. Les abonnements SaaS actifs continuent d’être renouvelés avec une cadence régulière. Microsoft fournit des notifications de webhook d’information uniquement pour les événements de renouvellement. Un client peut désactiver le renouvellement automatique pour un abonnement SaaS via le portail d’administration Microsoft 365. Dans ce cas, l’abonnement SaaS est automatiquement annulé à la fin de la période de facturation actuelle. Les clients peuvent également annuler l’abonnement SaaS à tout moment.

Seuls les abonnements actifs sont renouvelés automatiquement. Les abonnements restent actifs pendant le processus de renouvellement et, si le renouvellement automatique réussit. Après le renouvellement, les dates de début et de fin de la période d’abonnement sont mises à jour aux dates du nouveau terme.

En cas d’échec d’une récupération automatique en raison d’un problème de paiement, l’abonnement devient suspendu et l’éditeur est averti.

Les e-mails de rappel pour le renouvellement sont envoyés à l’acheteur et au propriétaire du compte de facturation, 30 jours avant la date de renouvellement annuel/multiannée.

Annulé (abonnement)

Les abonnements atteignent cet état une fois qu’une action client ou CSP explicite a lieu pour annuler l’abonnement. Ils annulent un abonnement à partir du site d’éditeur, du portail Azure ou du Centre d’administration Microsoft 365. Un abonnement est également annulé implicitement, à la suite d’un non-paiement des frais et après avoir été dans l’état suspendu pendant 30 jours.

Une fois que l’éditeur reçoit un appel de webhook d’annulation, il doit conserver les données client pour la récupération pendant au moins sept jours. Seules les données client peuvent être supprimées.

Un abonnement SaaS peut être annulé à tout moment dans son cycle de vie. Une fois qu’un abonnement est annulé, il ne peut pas être réactivé.

L’e-mail d’annulation est envoyé à la fois à l’acheteur et au propriétaire du compte de facturation.

Contenu connexe

• API d’abonnement de traitement SaaS v2
• API d’opérations de traitement SaaS v2

didacticiels vidéo

• créer un portail d’éditeur SaaS simple dans .NET
• à l’aide de l’API de traitement REST de l’offre SaaS