> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Gérer les produits d'abonnement à partir de votre service > Explique comment utiliser le service Recurrence pour interroger et gérer vos produits d'abonnement et prendre en charge les différents états d'abonnement d'un utilisateur. Pour les produits d'abonnement, utilisez un service principal (back-end) pour valider l'état et gérer les opérations de cycle de vie. L'utilisation des API Recurrence offre à vos équipes de soutien et d'exploitation en direct un moyen fiable d'inspecter, de prolonger ou d'annuler des abonnements. Cet article explique comment utiliser les points de terminaison Recurrence dans ces scénarios. ## Utilisation de la bibliothèque .NET Microsoft.StoreServices et de l'exemple Pour illustrer les principes et les flux décrits dans cet article, consultez l'exemple Microsoft.StoreServices. L'exemple utilise la bibliothèque Microsoft.StoreServices pour gérer l'authentification et effectuer les appels aux services du Microsoft Store. Le service d'exemple contient lui-même une logique type pour gérer les produits d'abonnement et fournit un guide de configuration pour le mettre en place. * [Microsoft.StoreServices (GitHub)](https://github.com/microsoft/Microsoft-Store-Services) * [Exemple Microsoft.StoreServices (GitHub)](https://github.com/microsoft/Microsoft-Store-Services-Sample) ## Types de produits d'abonnement Les types de produits d'abonnement gérés par le Store et d'abonnement en tant que module complémentaire fonctionnent tous deux avec le service Recurrence pour afficher et gérer l'abonnement de l'utilisateur. Pour plus d'information sur chacun de ces types de produits, consultez [Choisir le bon type de produit](/fr-CA/publishing/xstore-commerce/xstore-choosing-product-type#subscriptions) ## Interroger l'abonnement d'un utilisateur Utilisez [purchase.mp.microsoft.com/v8.0/b2b/recurrences/query](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-query) comme point de terminaison principal pour l'état des abonnements. Il renvoie les périodes d'abonnement actives et historiques, ainsi que le `subscriptionId` nécessaire aux opérations de modification. Il inclut également les champs requis pour distinguer les périodes de grâce (Grace) et de relance (Dunning). Les API Collections ([b2bLicensePreview (v8)](/fr-CA/reference/microsoft-store-apis/xstore-v8-query-for-products) et [publisherQuery (v9)](/fr-CA/reference/microsoft-store-apis/xstore-v9-query-for-products)) peuvent indiquer un droit d'utilisation d'abonnement actif, mais pas le même niveau de détail sur la récurrence. ## Délai entre la satisfaction des vérifications de droits d'utilisation sur le client et en mode serveur à serveur Lorsque vous publiez une mise à jour qui ajoute de nouveaux éléments (droits d'utilisation satisfaisants) à un ensemble, il existe un délai de visibilité des nouveaux éléments entre les requêtes d'API côté client et les requêtes serveur à serveur. Ce délai survient parce que les différents systèmes du Store mettent à jour leurs caches de catalogue à des intervalles différents. Lorsque la modification est publiée dans le catalogue, les services de licences locaux obtiennent généralement les informations mises à jour en premier, et les caches utilisés par publisherQuery les reçoivent de deux à trois heures plus tard. Prévoyez donc quelques heures pendant lesquelles les API côté client accordent l'accès alors que vos appels serveur à serveur ne reflètent pas encore la propriété des nouveaux éléments. Le service Recurrence lui-même n'est pas affecté; seuls les points de terminaison publisherQuery ou b2bLicensePreview qui interrogent les droits d'utilisation satisfaisants des éléments nouvellement ajoutés le sont. ### Comprendre les dates de début, de renouvellement et d'expiration des abonnements La date `StartTime` d'un abonnement est la date à laquelle l'abonnement actif a commencé. Si l'abonnement est configuré pour le renouvellement automatique, la date de début reste la même, mais les dates d'expiration changent à mesure que l'abonnement est renouvelé au cours des mois suivants. Si un abonnement est annulé, expire ou est révoqué, un nouvel objet d'abonnement est créé lorsque l'utilisateur achète de nouveau l'abonnement. La nouvelle période d'abonnement active a comme `StartTime` le jour où l'utilisateur a activé ou acheté le nouvel abonnement. Les périodes d'abonnement dans le Microsoft Store sont normalement configurées en nombre de mois. Par exemple, 1 mois, 3 mois ou 12 mois. Lorsqu'un utilisateur achète un abonnement d'un mois, la valeur `StartTime` correspond à minuit UTC (00:00:00) du jour où il a commencé l'abonnement. `ExpirationTime` correspond au nombre de mois (et non de jours) ajouté à `StartTime`, moins une seconde (23:59:59 UTC).\ Cette valeur fait en sorte que l'abonnement expire juste avant minuit UTC. Cependant, certains mois comptent un nombre de jours différent, ce qui crée un conflit pour les abonnements commençant le 29, le 30 ou le 31 d'un mois.\ Si la valeur `StartTime` de l'utilisateur tombe l'un de ces jours, la valeur `ExpirationTime` est modifiée pour correspondre à 23:59:59 UTC le dernier jour du mois d'expiration. Ainsi, la date de renouvellement est toujours minuit UTC (00:00:00) le premier jour du mois par la suite, et la valeur `ExpirationTime` est toujours 23:59:59 UTC le dernier jour du mois. #### Exemple de comportement des dates de début, de renouvellement et d'expiration d'un abonnement d'un mois | Date d'achat | StartTime | ExpireTime | Date de renouvellement automatique | Jours actifs | | - | - | - | - | - | | 2023-02-27T12:00:00Z | 2023-02-27T00:00:00Z | 2023-03-26T23:59:59Z | 2023-03-27T00:00:00Z | 28 | | 2023-03-27T12:00:00Z | 2023-03-27T00:00:00Z | 2023-04-26T23:59:59Z | 2023-05-27T00:00:00Z | 31 | | 2023-03-29T12:00:00Z | 2023-03-29T00:00:00Z | 2023-04-30T23:59:59Z | 2023-05-01T00:00:00Z | 32 | | 2023-04-29T12:00:00Z | 2023-04-29T00:00:00Z | 2023-05-31T23:59:59Z | 2023-06-01T00:00:00Z | 33 | | 2023-04-30T12:00:00Z | 2023-04-30T00:00:00Z | 2023-05-31T23:59:59Z | 2023-06-01T00:00:00Z | 32 | | 2024-02-27T12:00:00Z | 2024-02-27T00:00:00Z | 2024-03-26T23:59:59Z | 2024-03-27T00:00:00Z | 29 (année bissextile) | ### Comprendre les états Grace et Dunning Si un paiement de renouvellement automatique échoue à `ExpirationTime`, l'abonnement passe à l'état Grace (période de grâce), puis à l'état Dunning (période de relance) si le problème n'est toujours pas résolu. Les deux périodes signalent l'état `InDunning`; déterminez donc la période en cours en comparant l'heure UTC actuelle à `ExpirationTimeWithGrace`. Pendant que l'abonnement d'un utilisateur est en période de grâce ou de relance, vous devriez aviser les utilisateurs de vérifier l'état de leur facturation sur [Services et abonnements du compte Microsoft](https://account.microsoft.com/services). Pour placer correctement un compte dans chacun de ces états à des fins de test, consultez [Tester les produits d'abonnement](#testing-subscription-products). #### Période de grâce Pendant la période de grâce, gardez les avantages de l'abonnement activés pendant que le Store tente de nouveau le paiement du renouvellement. Si le renouvellement réussit, les jours de grâce utilisés sont déduits de la période suivante. Si le paiement n'est pas réglé avant `ExpirationTimeWithGrace`, l'abonnement passe à la période de relance. #### Période de relance La période de relance commence à la fin de la période de grâce. Désactivez les avantages de l'abonnement pendant cette période. Les utilisateurs ne peuvent pas racheter ni échanger le même abonnement pendant la période de relance. Si le paiement n'est toujours pas réglé à la fin de la période de relance, l'abonnement devient inactif. ### Durées des périodes de grâce et de relance | Type d'abonnement | Durée de l'abonnement | Grâce | Relance (après la grâce) | | - | - | - | - | | Abonnement en tant que module complémentaire | Toute | 3 jours | 39 jours | | Abonnement géré par le Store | Toute | 7 jours | 36 jours | ## Modifier l'abonnement d'un utilisateur Vos services peuvent également modifier des abonnements avec [purchase.mp.microsoft.com/v8.0/b2b/recurrences/](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-change){recurrenceId}[/change](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-change). Les opérations prises en charge comprennent l'ajout de jours, la désactivation du renouvellement automatique et l'annulation de l'abonnement. Votre service a besoin du `recurrenceId` (même valeur que `id` de l'[API RecurrenceQuery](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-query) et des valeurs `recurrenceData` de l'[API de requête Collections](/fr-CA/reference/microsoft-store-apis/xstore-v9-query-for-products)) pour agir sur l'abonnement de l'utilisateur. Voici quelques exemples de la façon dont le point de terminaison Recurrence Change peut être utile à vos services : * Ajouter du temps aux abonnements des utilisateurs touchés par une interruption de service. * Intégration avec vos équipes de soutien à la clientèle pour aider les utilisateurs en leur donnant de l'information sur l'état de leur abonnement, les annulations, etc. * Interface utilisateur en jeu permettant aux utilisateurs de modifier des paramètres comme le renouvellement automatique ou de mettre fin à leur abonnement. ## Tester les produits d'abonnement L'[API Recurrence Change](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-change) peut aussi servir aux tests. `Extend` accepte des valeurs de jours négatives, ce qui vous permet de faire avancer un abonnement de test vers les états ciblés. ### Tester les états Active, Inactive et Canceled Lorsque vous testez les états Active, Inactive et Canceled d'un abonnement, vous pouvez utiliser un prix de base de 0,00 \$ pour l'abonnement. Ajoutez l'abonnement au compte de test pour vérifier l'état Active, puis utilisez le point de terminaison Recurrence Change pour désactiver le renouvellement automatique. Utilisez ensuite le point de terminaison Recurrence Change pour annuler l'abonnement ou soustraire suffisamment de jours pour que la valeur `ExpirationTime` soit antérieure à la date et l'heure UTC actuelles. ### Tester les états Grace et Dunning Pour tester les états Grace et Dunning, l'abonnement doit avoir un prix non nul.\ De plus, le compte de test doit être configuré de façon à ce que les paiements subséquents échouent lorsque la valeur `ExpirationTime` est dépassée. Actuellement, le Microsoft Store n'offre pas de moyens de paiement de test; la façon la plus simple de configurer un compte consiste donc à utiliser des codes de devise prépayée comme suit : 1. Configurez l'abonnement avec un prix bas, par exemple 0,99 \$, dans votre environnement de test. 2. [Achetez une carte-cadeau prépayée XBOX](https://www.microsoft.com/en-us/p/xbox-gift-card-digital-code/cfq7ttc0k63h/0002?activetab=pivot:overviewtab) de 1,00 $ou 2,00$ pour couvrir le premier achat de l'abonnement (taxes comprises), mais pas le renouvellement. 3. Échangez la carte-cadeau sur votre compte de test. 4. Achetez l'abonnement sur le compte de test. 5. Assurez-vous que le renouvellement automatique est activé pour l'abonnement, mais que les fonds sont insuffisants pour renouveler l'abonnement. 6. Utilisez Recurrence Change pour déplacer la valeur `ExpirationTime` de l'abonnement dans les prochaines 24 heures (voir la remarque suivante). 7. Attendez que la valeur `ExpirationTime` soit dépassée naturellement et que l'état affiche `InDunning` (cela peut prendre jusqu'à 24 heures après `ExpirationTime`). Pour obtenir un comportement exact Grace -> Dunning -> Inactive, laissez le compte évoluer naturellement après avoir configuré le test. > [!NOTE] > > Pour placer correctement un compte dans l'état 'InDunning' pour les périodes de grâce et de relance, le compte doit dépasser naturellement les dates `ExpirationTime` et `ExpirationTimeWithGrace`. Lorsque vous soustrayez des jours, ciblez une valeur `ExpirationTime` dans les prochaines 24 heures, puis laissez le temps s'écouler naturellement. Si vous déplacez `ExpirationTime` à un moment déjà passé, l'état `InDunning` pourrait ne pas apparaître et l'état de test peut devenir invalide. La seule façon de résoudre ce problème est d'annuler l'abonnement et de créer un nouvel abonnement de test. ## Voir aussi [Vue d'ensemble du commerce](/fr-CA/publishing/xstore-commerce/xstore-commerce-overview) [API de service du Microsoft Store](/fr-CA/reference/microsoft-store-apis/index) [purchase.mp.microsoft.com/v8.0/b2b/recurrences/query](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-query) [purchase.mp.microsoft.com/v8.0/b2b/recurrences/](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-change){recurrenceId}[/change](/fr-CA/reference/microsoft-store-apis/xstore-v8-recurrence-change)  [Bibliothèque Microsoft.StoreServices (GitHub)](https://github.com/microsoft/Microsoft-Store-Services) [Exemple Microsoft.StoreServices (GitHub)](https://github.com/microsoft/Microsoft-Store-Services-Sample) ## Related topics - [Détecter l'accès à un abonnement XBOX Game Pass à partir de votre service](/fr-CA/publishing/xstore-commerce/xstore-detecting-game-pass.md) - [Gestion des produits consommables à partir de votre service](/fr-CA/publishing/xstore-commerce/xstore-managing-consumables.md) - [Choix du type de produit approprié](/fr-CA/publishing/xstore-commerce/xstore-choosing-product-type.md) - [Accorder aux joueurs l'accès au contenu des modules complémentaires](/fr-CA/publishing/xstore-commerce/xstore-granting-access.md) - [API de service du Microsoft Store (contenu)](/fr-CA/reference/microsoft-store-apis/xstore-nav.md)