Apple et Google vous laissent prolonger la date de renouvellement d'un abonnement après une panne, et leurs limites n'ont rien à voir

Une panne offre à chaque abonné l'argument de remboursement le plus imparable qui soit, et vous ne pouvez pas l'empêcher de s'en servir. Ce que vous pouvez faire, c'est rendre les jours perdus avant que quiconque les réclame. Les deux stores vous permettent de prolonger la date de renouvellement d'un abonnement pour que le client reçoive du temps gratuit au lieu d'argent. Apple plafonne chaque prolongation à 90 jours et en autorise deux par an. Google vous laisse reporter la facturation jusqu'à un an par appel. Les démarches, les notifications et la facture sous-jacente diffèrent assez pour qu'un seul plan de crise ne couvre pas les deux.

Ce qu'une panne change à votre exposition aux remboursements

Ce sont les stores qui décident des remboursements, pas vous. Sur l'App Store, le client s'adresse à Apple et Apple tranche. Vous pouvez recevoir une notification CONSUMPTION_REQUEST et disposer de 12 heures pour envoyer des données de consommation via Send Consumption Information. C'est tout ce que vous avez à dire.

Sur Google Play, un acheteur peut obtenir un remboursement dans les 48 heures suivant l'achat sans qu'on vous demande votre avis. Ensuite, les demandes vous parviennent. Le seul parcours Google qui sollicite vos preuves est une rétrofacturation signalée pour examen par le développeur, à laquelle vous répondez via orders.reviewrefund sous 24 heures. La décision de la banque sur une rétrofacturation est définitive.

Aucun des deux stores ne vous donne donc le moyen de bloquer un remboursement. Ce que vous maîtrisez, c'est le fait qu'un abonné se sente encore lésé quand le service revient. Du temps supplémentaire sur l'abonnement, accordé vite et annoncé clairement, est l'outil que les deux stores ont conçu précisément pour cela.

Comment prolonger la date de renouvellement d'un abonnement sur l'App Store

L'App Store Server API propose deux endpoints pour cela. Extend a Subscription Renewal Date agit sur un abonnement, que vous identifiez par son originalTransactionId. Extend Subscription Renewal Dates for All Active Subscribers agit sur tous les abonnés éligibles d'un productId, et vous pouvez le limiter avec storefrontCountryCodes quand la panne n'a touché que certaines régions.

Chaque requête contient trois éléments : extendByDays, un nombre de 1 à 90 ; un extendReasonCode ; et un requestIdentifier que vous générez. Le code de motif 3 correspond à un problème ou une panne du service. Le code 1 correspond à la satisfaction client, le code 2 à d'autres raisons et le code 0 à un motif non déclaré.

Les abonnements qu'Apple accepte de prolonger

Seuls les abonnements à renouvellement automatique actifs ayant au moins une période déjà payée sont éligibles. Apple écarte ceux-ci :

• Les abonnements en période d'offre gratuite, comme un essai gratuit.
• Les abonnements inactifs en état de nouvelle tentative de facturation.
• Les abonnements en délai de grâce de facturation dont la date d'expiration est passée.
• Les abonnements qui ont déjà reçu deux prolongations de la date de renouvellement au cours des 365 derniers jours.
• Les abonnements expirés.

Le Partage familial suit sans effort. Quand Apple prolonge un abonnement acheté compatible avec le Partage familial, les abonnements des membres de la famille sont prolongés aussi. Vous ne pouvez pas cibler directement l'abonnement d'un membre de la famille.

La requête groupée est lente, surveillez donc les notifications

Apple indique qu'une requête de prolongation pour tous les abonnés actifs peut prendre des heures, voire des jours, selon le nombre d'abonnés. Une réponse 200 signifie seulement qu'Apple la traite. App Store Server Notifications V2 vous dit comment cela s'est passé :

Pour chaque FAILURE, récupérez l'originalTransactionId dans la transaction signée du payload et relancez-le avec l'endpoint pour un seul abonnement. Si vous préférez interroger l'API, Get Status of Subscription Renewal Date Extensions indique si la requête est terminée et combien de prolongations ont réussi ou échoué.

Comment fonctionne le report de facturation de Google Play

La version de Google s'appelle purchases.subscriptionsv2.defer, appelée une fois par jeton d'achat. Le corps de la requête contient un deferralContext à trois champs. L'etag provient de purchases.subscriptionsv2.get, et l'appel échoue s'il ne correspond pas au dernier etag de l'abonnement. Le deferDuration indique de combien repousser la date. Enfin, validateOnly, s'il vaut true, exécute la requête à blanc sans toucher à l'abonnement.

Le guide de facturation de Google fixe la plage d'un jour à un an par appel d'API. Pour aller plus loin, appelez de nouveau avant la nouvelle date d'expiration. Pour un abonnement à renouvellement automatique, le report déplace la prochaine date de renouvellement. Pour une formule prépayée, il déplace l'heure d'expiration. Sur un abonnement avec modules complémentaires, chaque élément est reporté de la même durée. La réponse liste le nouvel expiryTime de chaque élément.

Pendant le report, l'utilisateur reste abonné avec un accès complet et n'est pas facturé pour le temps supplémentaire. Google envoie une notification en temps réel pour les développeurs SUBSCRIPTION_DEFERRED. L'ancienne méthode purchases.subscriptions.defer est obsolète, le nouveau code doit donc utiliser la méthode v2.

Google ne prévient pas votre client, c'est donc à vous de le faire

Apple envoie un e-mail au client après chaque prolongation réussie. Le guide de facturation de Google ne décrit aucun message à l'utilisateur. Si le but est de devancer les demandes de remboursement, l'abonné doit savoir que ce temps supplémentaire existe. Prévenez-le vous-même, dans l'app et par e-mail, en précisant combien de jours et pourquoi.

Apple et Google côte à côte

Ce que coûte une prolongation par rapport à un remboursement

Un remboursement et une prolongation puisent l'argent à des endroits différents. Un remboursement rend ce que le client a payé pour la période. Tout ce que vous avez déjà dépensé pour servir ce client reste dépensé : le calcul de chaque session, les appels à l'API du modèle, le stockage et tout versement à un créateur dont il a utilisé le contenu.

Une prolongation conserve le paiement. Ce qu'elle coûte, c'est le service fourni sans renouvellement pour le financer. Chaque jour ajouté, un abonné actif continue de générer les mêmes factures. Pour un utilisateur occasionnel, c'est presque rien. Pour un gros utilisateur d'une fonctionnalité d'IA, 30 jours supplémentaires peuvent représenter 30 jours d'appels au modèle sans aucun revenu en face. Dimensionnez la prolongation selon la panne, pas selon les excuses que vous aimeriez présenter.

Le coût en commission chez Apple

Apple verse 70 % de chaque renouvellement pendant la première année de service payé d'un abonné, puis 85 %. La page d'Apple sur les abonnements indique que les jours de prolongation du renouvellement sont exclus des jours de service payé. Une prolongation de 30 jours repousse donc de 30 jours le passage de cet abonné à 85 %. Si vous faites partie de l'App Store Small Business Program, vous recevez déjà 85 % et ce coût ne s'applique pas.

Le coût des rétrofacturations sur Google Play

Pour les commandes passées après le 3 août 2026, une rétrofacturation gagnée par le titulaire de la carte coûte à un développeur Google Play le prix d'achat moins les frais de service de Play, plus les frais bancaires. Une panne est exactement le genre d'événement qui pousse un client agacé vers sa banque. Un report qui lui parvient avant revient moins cher qu'un litige que vous ne pouvez pas renverser.

Quand une prolongation n'est pas le bon outil

L'achat n'était pas un abonnement

Les prolongations de la date de renouvellement ne s'appliquent qu'aux abonnements. Si une panne a cassé un consommable ou un déblocage unique, livrez de nouveau l'élément. Si Apple envoie un CONSUMPTION_REQUEST à son sujet, déclarez ce qui s'est passé. Le champ deliveryStatus d'Apple prévoit une valeur pour cela, UNDELIVERED_SERVER_OUTAGE, et Apple précise que tout statut autre que DELIVERED doit s'accompagner d'un consumptionPercentage à 0.

Le client a déjà utilisé ses deux prolongations Apple

Le plafond d'Apple est de deux prolongations par client sur 365 jours. Deux pannes dans l'année les épuisent, et une troisième vous laisse sans rien à offrir via le store. Suivez le nombre de prolongations utilisées par chaque originalTransactionId, pour que les notifications FAILURE de la requête groupée ne vous prennent pas au dépourvu.

Le client est en essai gratuit

Apple ne prolonge pas un abonnement en période d'offre gratuite. Un utilisateur en essai a perdu des jours gratuits, pas des jours payés, donc le risque de remboursement est faible. Si vous voulez le dédommager, un message dans l'app coûte moins cher que n'importe quel appel d'API.

Une checklist pour la prochaine panne

• Notez quand la panne a commencé et fini, et quels produits et régions elle a touchés.
• Choisissez un nombre de jours qui couvre le temps perdu. Chez Apple, utilisez le code de motif 3 et restez entre 1 et 90.
• Chez Apple, envoyez une requête groupée par productId, limitée par storefrontCountryCodes quand seules certaines régions ont été touchées.
• Surveillez les notifications RENEWAL_EXTENSION FAILURE et relancez chacune avec l'endpoint pour un seul abonnement.
• Sur Google Play, parcourez les jetons d'achat actifs, lisez chaque etag, lancez d'abord avec validateOnly, puis reportez pour de vrai.
• Prévenez vous-même les abonnés Google Play du temps supplémentaire, puisque Google ne le fera pas.
• Mettez à jour l'expiration des droits d'accès à partir de RENEWAL_EXTENDED et SUBSCRIPTION_DEFERRED, pas de vos propres calculs de dates.
• Conservez des journaux d'utilisation par compte, pour que si une demande de remboursement ou une rétrofacturation arrive malgré tout, vos preuves soient prêtes en moins de 12 heures pour Apple et 24 heures pour Google.