Réduire le churn sur Google Play : grace period et account hold
Comment fonctionnent grace period et account hold sur Google Play, quelles notifications RTDN traiter, les messages in-app sur les refus, et la reconquête.
Par Florian
Sur Google Play, c’est Google qui débite le client, relance les paiements échoués et affiche le bouton de résiliation. Vous ne pouvez ni relancer un paiement ni toucher au moyen de paiement du client. Ce que vous maîtrisez : la durée de la grace period (délai de grâce) et de l’account hold (suspension du compte), le maintien ou non de l’accès, ce que votre appli affiche au client, et la vitesse à laquelle vous réagissez quand un abonnement se rétablit ou prend fin.
Ce guide couvre la grace period, l’account hold, les notifications en temps réel pour les développeurs (RTDN) et les états subscriptionsv2 qui les sous-tendent, les messages dans l’appli pour les refus de paiement, les deep links vers le centre des abonnements, la restauration et la réinscription, et les achats annulés. Il s’en tient à la documentation de Google : cycle de vie des abonnements, à propos des abonnements, la référence RTDN et Aider Google à contester les chargebacks (tous consultés en novembre 2026).
Ce que fait Google quand un renouvellement échoue
Quand un paiement de renouvellement échoue, Google prévient l’utilisateur et continue d’essayer de renouveler pendant un certain temps avant que l’abonnement prenne fin. La documentation de Google appelle cela la période de récupération, composée d’une grace period suivie d’un account hold. Pendant ce temps, Google envoie à l’utilisateur des emails et des notifications lui demandant de mettre à jour son moyen de paiement.
| Phase | Accès de l’utilisateur | subscriptionState |
RTDN au début |
|---|---|---|---|
| Grace period | Garde l’accès | SUBSCRIPTION_STATE_IN_GRACE_PERIOD |
SUBSCRIPTION_IN_GRACE_PERIOD (6) |
| Account hold | Perd l’accès | SUBSCRIPTION_STATE_ON_HOLD |
SUBSCRIPTION_ON_HOLD (5) |
| Rétabli | Accès rétabli | SUBSCRIPTION_STATE_ACTIVE |
SUBSCRIPTION_RECOVERED (1) |
| Non rétabli | Accès terminé | SUBSCRIPTION_STATE_CANCELED, puis EXPIRED |
SUBSCRIPTION_CANCELED (3), puis SUBSCRIPTION_EXPIRED (13) |
Grace period
Le guide du cycle de vie de Google indique :
- La grace period est activée par défaut sur tous les forfaits de base à renouvellement automatique. Vous pouvez changer sa durée ou la désactiver dans la Play Console, et Google prévient qu’une durée plus courte peut réduire le nombre d’abonnements récupérés.
- Pendant la grace period, l’utilisateur doit garder l’accès.
autoRenewEnabledreste àtrue, et Google prolongeexpiryTimejusqu’à la fin de la grace period. - Si l’utilisateur corrige son moyen de paiement, l’abonnement se renouvelle à sa date de renouvellement d’origine.
- Changer la durée de la grace period n’affecte que les renouvellements qui entrent en grace period après le changement.
- Si vous réglez 0 jour, Google attend quand même au moins 1 jour (une « grace period silencieuse ») pour laisser le temps aux relances. L’abonnement reste actif pendant ces 24 heures et vous ne recevrez pas de RTDN de grace period.
Si votre appli n’utilise que queryPurchasesAsync() pour vérifier les droits d’accès, les grace periods sont gérées pour vous, car la Play Billing Library continue de renvoyer ces achats comme actifs.
Account hold
L’account hold suit la grace period :
- Il est activé par défaut, et sa durée par défaut est de 60 jours moins la grace period. Vous pouvez la changer ou le désactiver dans la Play Console, avec le même avertissement sur les durées plus courtes.
- Avant que l’abonnement entre en account hold, Google fait des tentatives de débit supplémentaires pendant jusqu’à 48 heures, pendant lesquelles l’utilisateur garde l’accès.
- Pendant l’account hold, vous devez bloquer l’accès.
expiryTimeest dans le passé etqueryPurchasesAsync()ne renvoie plus l’abonnement. - Si l’utilisateur règle son paiement, vous recevez
SUBSCRIPTION_RECOVERED, le purchase token reste le même, et vous devez rétablir l’accès. Contrairement à la récupération pendant la grace period, la date de facturation passe à la date de récupération. - Si l’account hold se termine sans correction, vous recevez
SUBSCRIPTION_CANCELEDpuisSUBSCRIPTION_EXPIRED. - Un abonnement en pause qui reprend avec un moyen de paiement qui échoue passe directement en account hold.
Google note aussi que les utilisateurs peuvent résilier, restaurer ou racheter pendant l’account hold : votre backend doit donc continuer à traiter ces événements.
Les notifications en temps réel pour les développeurs
Les RTDN sont livrées via Cloud Pub/Sub et ne portent que le type de notification et le purchase token. Google recommande d’appeler purchases.subscriptionsv2.get depuis votre backend à chaque notification pour lire l’état complet. La référence RTDN liste les types d’abonnement ; ceux qui comptent le plus pour le churn :
| Code | Type | Que faire |
|---|---|---|
| 6 | SUBSCRIPTION_IN_GRACE_PERIOD |
Garder l’accès ; demander à l’utilisateur de régler son paiement |
| 5 | SUBSCRIPTION_ON_HOLD |
Retirer l’accès ; expliquer pourquoi à l’utilisateur |
| 1 | SUBSCRIPTION_RECOVERED |
Rétablir l’accès (aussi envoyé quand un abonnement reprend après une pause) |
| 2 | SUBSCRIPTION_RENEWED |
Renouvellement normal |
| 3 | SUBSCRIPTION_CANCELED |
Résiliation volontaire ou involontaire ; vérifier canceledStateContext |
| 7 | SUBSCRIPTION_RESTARTED |
L’utilisateur a restauré un abonnement résilié pas encore expiré |
| 12 | SUBSCRIPTION_REVOKED |
Révoqué avant l’expiration, par exemple après un chargeback ; retirer l’accès |
| 13 | SUBSCRIPTION_EXPIRED |
Retirer l’accès |
| 4 | SUBSCRIPTION_PURCHASED |
Nouvel achat, y compris une réinscription |
Lors d’une résiliation, canceledStateContext vous dit si c’est l’utilisateur, le système ou vous qui avez résilié, et pour les résiliations par l’utilisateur, userInitiatedCancellation peut inclure la raison qu’il a donnée. Servez-vous-en : une résiliation après un account hold est un problème de paiement, pas une décision de partir.
Les messages dans l’appli pour les refus de paiement
Google propose un message tout prêt pour les problèmes de paiement. Si vous appelez BillingClient.showInAppMessages() avec InAppMessageCategoryId.TRANSACTIONAL, Google Play affiche un snackbar temporaire qui informe l’utilisateur que son paiement a été refusé, avec un deep link pour corriger son moyen de paiement sur Google Play. D’après le guide des abonnements de Google, le message est affiché une fois par jour pendant la grace period et l’account hold, et Google recommande d’appeler l’API à chaque ouverture de l’appli.
Si l’utilisateur règle son paiement, l’appel renvoie SUBSCRIPTION_STATUS_UPDATED avec un purchase token. Rafraîchissez l’abonnement depuis votre backend et rétablissez l’accès tout de suite.
Pour les utilisateurs qui accèdent à votre contenu hors de l’appli (sur le web, par exemple), Google suggère une notification push ou un email quand l’accès s’arrête à cause de l’account hold.
Les deep links vers le centre des abonnements
Votre appli doit renvoyer vers la gestion des abonnements depuis son écran de réglages. Google documente deux URL :
- Tous les abonnements :
https://play.google.com/store/account/subscriptions - Un abonnement précis (recommandé) :
https://play.google.com/store/account/subscriptions?sku=your-sub-product-id&package=your-app-package
La seconde ouvre la page de gestion de cet abonnement, où l’utilisateur peut gérer ses moyens de paiement, résilier, se réabonner ou mettre en pause. Utilisez-la aussi dans vos propres emails de paiement.
Restauration, réinscription et reconquête
Google distingue deux actions, toutes deux présentées à l’utilisateur sous la forme d’un bouton Resubscribe dans le Play Store :
- Restauration : avant l’expiration, un abonnement résilié est restauré et continue de se renouveler comme s’il n’avait jamais été résilié. Il garde le même purchase token et vous recevez
SUBSCRIPTION_RESTARTED. Google indique que toutes les applis doivent prendre en charge la restauration. - Réinscription : après l’expiration, si le forfait de base le permet, l’utilisateur rachète depuis le Play Store. C’est un nouvel achat, avec un nouveau token et une RTDN
SUBSCRIPTION_PURCHASED. Vous devez l’accuser (acknowledge) ; le champoutOfAppPurchaseContextvous aide à le relier à l’abonnement et à l’utilisateur précédents.
Dans votre appli, le guide de Google décrit la reconquête des utilisateurs qui ont résilié en leur proposant un écran de réinscription (par exemple avec un bouton Réactiver), avant ou après l’expiration. Les offres d’abonnement peuvent cibler les utilisateurs éligibles avec des remises ; les règles d’éligibilité se définissent dans la Play Console.
Remboursements, achats annulés et chargebacks
Quand un achat est remboursé ou fait l’objet d’un chargeback, il est annulé (voided). Vous recevez une RTDN voidedPurchaseNotification avec le purchase token, l’ID de commande, le productType et le refundType (remboursement total ou remboursement partiel par quantité). Le guide du cycle de vie de Google ajoute qu’un abonnement qui fait l’objet d’un chargeback, ou qui est révoqué par votre backend avec purchases.subscriptionsv2.revoke, déclenche SUBSCRIPTION_REVOKED, et que vous devez retirer l’accès. La Voided Purchases API vous donne plus de détails sur une plage de dates.
Pour les chargebacks, Google vous permet de donner votre avis. Quand un chargeback demande une revue du développeur, Google Play envoie une RTDN PendingRefundReviewNotification, et vous avez 24 heures pour répondre avec la ReviewRefund API, en donnant une préférence de remboursement et toute preuve d’usage de l’achat. Google n’enregistre que votre premier appel.
Une liste de contrôle
- Les RTDN sont livrées à votre backend, et chacune déclenche un
subscriptionsv2.get. - La grace period et l’account hold sont activés, avec des durées choisies délibérément.
- L’accès est maintenu pendant la grace period et coupé pendant l’account hold.
-
showInAppMessages()est appelé au lancement de l’appli. - Votre écran de réglages et vos emails utilisent le deep link de l’abonnement précis.
- Les achats de restauration et de réinscription sont traités et accusés.
- Chaque achat porte un ID de compte obfusqué, pour pouvoir le rattacher à votre utilisateur.
- Les achats annulés et les notifications de revue de chargeback sont traités.
Le faire avec NoChurn
Google garde les paiements, les relances, la grace period, l’account hold et le bouton de résiliation ; NoChurn n’y change rien. NoChurn lit vos notifications en temps réel pour les développeurs, rattache chaque abonnement à votre utilisateur via l’ID de compte obfusqué, et place grace periods, account holds, résiliations, récupérations et achats annulés dans la chronologie du client et dans un score de churn de 0 à 100. Là où Google le permet, NoChurn agit : messages dans votre appli ou par email renvoyant vers la page d’abonnement de Play, un parcours d’annulation que votre appli affiche via l’API headless avant de renvoyer vers Google Play, et des emails de reconquête à J30, J60 et J90 selon la raison de la résiliation. Voir NoChurn + Google Play.