Si votre app utilise encore App Store Server Notifications V1, Apple ne vous consulte jamais sur les remboursements d'abonnements

La version 1 d'App Store Server Notifications transmet toujours les remboursements, mais elle omet la seule notification qui vous permet de défendre votre position sur un remboursement d'abonnement. Apple a rendu V1 obsolète le 5 juin 2023, en même temps que l'endpoint verifyReceipt, et n'a depuis ajouté toutes les fonctionnalités liées aux remboursements qu'à V2. Si vos réglages App Store Connect indiquent encore Version 1, Apple peut trancher un remboursement d'abonnement sans jamais envoyer de CONSUMPTION_REQUEST à votre serveur. Vous ne perdez pas un litige. Vous n'y êtes jamais convié.

Ce que signifie l'obsolescence d'App Store Server Notifications V1 chez Apple

Obsolète ne veut pas dire désactivé. Un ingénieur d'Apple a écrit sur les forums développeurs en juin 2023 que verifyReceipt et les notifications V1 continueraient de fonctionner jusqu'à l'annonce d'une date de fin, que cette date n'était pas fixée et que les développeurs seraient prévenus à l'avance. Plus de trois ans plus tard, App Store Connect propose toujours "Version 1 (deprecated)" parmi les choix lorsque vous définissez une URL de serveur.

En revanche, l'obsolescence signifie un gel. Chaque modification du journal des changements des notifications d'Apple depuis juin 2023 concerne V2 : nouveaux champs dans la transaction signée, nouveaux types de notifications, données d'engagement sur 12 mois ajoutées en avril 2026. Un serveur V1 n'en voit rien.

Les signaux de remboursement qu'un serveur V1 ne reçoit jamais

Voici comment les mêmes événements de remboursement parviennent à un serveur V1 et à un serveur V2, d'après la documentation d'Apple pour chaque version.

V1 reçoit-il encore CONSUMPTION_REQUEST ?

Oui, pour les consommables. La référence V1 d'Apple décrit CONSUMPTION_REQUEST comme la notification envoyée lorsqu'un client lance une demande de remboursement pour un achat intégré consommable. Un ingénieur d'Apple a confirmé sur les forums en 2023 que les demandes de consommation V1 sont envoyées pour les remboursements éligibles. Le manque concerne les abonnements. Le journal des changements d'Apple date les demandes de consommation d'abonnements du 11 avril 2024, en V2, et la documentation de Send Consumption Information précise qu'Apple envoie la demande via votre endpoint V2.

Pourquoi CANCEL en V1 est facile à mal interpréter

En V1, lorsqu'Apple rembourse un abonnement, le type de notification est CANCEL, souvent accompagné de DID_CHANGE_RENEWAL_STATUS. De nombreux serveurs traitent toute annulation comme un client qui désactive le renouvellement automatique, ce qui laisse l'accès actif jusqu'à la fin de la période. V2 lève l'ambiguïté. Un remboursement arrive sous la forme REFUND, et un client qui désactive le renouvellement arrive sous la forme DID_CHANGE_RENEWAL_STATUS avec le sous-type AUTO_RENEW_DISABLED.

Ce que coûte, en argent, le maintien en V1

Apple tranche chaque remboursement sur l'App Store. Le CONSUMPTION_REQUEST est le seul moment où vos données d'utilisation parviennent à cette décision, et Apple vous demande de répondre dans un délai de 12 heures. En V1, les remboursements d'abonnements sautent cette étape.

Voici un exemple chiffré à titre indicatif. Supposons que votre app vende un abonnement mensuel à $9.99 qui inclut des générations d'images par IA. Un abonné lance 400 générations en un mois, et chacune vous coûte de l'argent bien réel en inférence de modèle. Puis il demande un remboursement à Apple.

Le paiement que vous perdez correspond à votre part, pas au prix affiché. Apple reverse 70% du prix d'un abonnement, hors taxes applicables, pendant la première année de service payant d'un abonné, puis 85% au-delà ou pour les membres de l'App Store Small Business Program. La facture de calcul, elle, ne diminue pas. L'inférence, les appels d'API tiers et le stockage de fichiers ont été payés au moment où le client les a utilisés.

Les deux notifications de résultat manquantes coûtent aussi de l'argent. Sans REFUND_REVERSED, un serveur qui a révoqué l'accès après un remboursement ne le rétablit jamais quand Apple annule ce remboursement, si bien qu'un client payant reste bloqué et écrit au support. Sans REFUND_DECLINED, vous ne pouvez pas distinguer un remboursement encore en attente d'un remboursement qu'Apple a refusé.

Comment migrer de V1 vers V2 sans perdre un seul remboursement

Passer à V2, c'est une modification côté serveur plus un réglage. Les propres indications d'Apple sur les forums, données par un App Store Commerce Engineer en décembre 2025, expliquent ce qui se passe le jour de la bascule.

Construisez l'endpoint V2 avant de changer le réglage

• Acceptez un POST dont le corps contient un signedPayload. Les payloads V2 sont des JWS signés par Apple. Vérifiez donc la signature avant de vous fier à leur contenu. L'App Store Server Library d'Apple s'en charge pour vous.
• Faites correspondre le traitement de CANCEL à REFUND, et gérez REFUND_DECLINED et REFUND_REVERSED comme de nouveaux cas.
• Répondez au CONSUMPTION_REQUEST des abonnements avec Send Consumption Information, et uniquement si le client a consenti au partage de données avec Apple. Apple indique que sans consentement, vous ne devez pas répondre.
• Renvoyez un code HTTP 200 à 206 en cas de succès. Tout code 40x ou 50x entraîne une relance par Apple.

Changez le réglage dans App Store Connect

Dans App Store Connect, ouvrez votre app, choisissez App Information sous General, repérez App Store Server Notifications et définissez la Production Server URL sur votre endpoint V2 en sélectionnant Version 2. Faites d'abord de même pour l'URL de sandbox si vous voulez tester, et utilisez Request a Test Notification pour vérifier que votre serveur répond.

Gardez le gestionnaire V1 actif pendant environ trois jours

Après la bascule, les nouvelles notifications arrivent immédiatement au format V2, pour tous les abonnements, anciens comme nouveaux. Les notifications V1 déjà en cours de relance continuent d'arriver au format V1 jusqu'à ce qu'elles aboutissent ou épuisent leurs relances. Apple situe la dernière relance V1 possible à environ 78 heures, soit 6 plus 24 plus 48. Laissez l'ancien gestionnaire tourner au-delà de ce délai, puis supprimez-le.

Remplacez verifyReceipt au passage

verifyReceipt a été rendu obsolète le même jour. Il répond toujours, mais Apple oriente les serveurs vers l'App Store Server API. Get Transaction Info renvoie une transaction signée, Get Transaction History renvoie l'historique d'un client et Get Refund History liste tous les achats remboursés d'un client. Associés aux notifications V2, ils couvrent ce pour quoi la plupart des serveurs utilisaient les reçus, y compris le champ cancellation_date qui signalait autrefois un remboursement dans un reçu.

RefundHalt se connecte à App Store Server Notifications V2 et répond à chaque CONSUMPTION_REQUEST dans la fenêtre de 12 heures, à partir de l'utilisation que votre app enregistre déjà. Si vous êtes encore en V1, la bascule est l'étape qui rend tout cela possible.