Manquer des notifications de remboursement peut vous coûter les seuls remboursements que vous pouvez contester, et les deux stores vous laissent les récupérer si vous regardez à temps

Manquer des notifications de remboursement, c'est la façon discrète dont un développeur perd les deux seules décisions de remboursement où il a voix au chapitre. Le CONSUMPTION_REQUEST d'Apple et l'examen de rétrofacturation de Google Play commencent tous deux par une notification, et tous deux se ferment sur un délai court : 12 heures chez Apple, 24 heures chez Google. Si votre serveur est en panne, lent ou mal configuré quand ce message arrive, le store ne vous attend pas. Il décide avec ce qu'il a déjà.

La bonne nouvelle, c'est qu'aucun des deux stores ne jette le message au premier échec. Apple relance et garde un historique de 180 jours que vous pouvez interroger. Google publie via Pub/Sub, qui conserve les messages non acquittés pendant des jours. La mauvaise nouvelle, c'est que le rythme des relances ne colle pas aux délais de réponse, et que l'une des deux procédures n'a aucune API de récupération.

Comment chaque store envoie les notifications de remboursement

Apple envoie les App Store Server Notifications directement à une URL HTTPS que vous définissez dans App Store Connect. Google n'appelle pas votre serveur directement. Il publie les notifications en temps réel pour les développeurs (Real-time developer notifications) sur un sujet Google Cloud Pub/Sub, et votre abonnement à ce sujet les pousse vers votre endpoint ou attend que votre serveur vienne les récupérer.

Ce qu'Apple considère comme un échec

La documentation d'Apple est précise. Renvoyez un statut entre 200 et 206 et la livraison est terminée. Renvoyez un 40x ou un 50x et Apple relance. Apple considère aussi tout autre code comme un échec. Chaque tentative est consignée avec un sendAttemptResult, et les valeurs ressemblent à une liste de vraies pannes : TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE et quelques autres. Pour TIMED_OUT, Apple conseille elle-même de vérifier que votre serveur ne traite pas les messages de façon synchrone.

Ce que Google considère comme un échec

Sur un abonnement push, un code de réponse de succès de votre endpoint vaut acquittement. Sur un abonnement pull, votre serveur doit acquitter chaque message qu'il récupère, sinon Pub/Sub le renvoie. Le délai d'acquittement par défaut est de 10 secondes et le maximum de 600 secondes. Le guide RTDN de Google ajoute une règle qui mérite d'être rappelée : une notification indique seulement que quelque chose a changé, vous devez donc toujours appeler la Google Play Developer API pour obtenir l'état complet de l'achat.

Pourquoi le calendrier de relances d'Apple ne tient pas dans le délai de 12 heures

Les intervalles de relance d'Apple se comptent depuis la tentative précédente, pas depuis la première. Additionnez-les et vous obtenez cette chronologie pour une seule notification V2 que votre serveur continue de manquer.

Apple vous demande de répondre dans les 12 heures suivant la réception du CONSUMPTION_REQUEST. Si votre serveur est en panne lors du premier envoi et de la relance une heure plus tard, la tentative suivante arrive 13 heures après la première. Apple ne précise pas si une demande reçue pour la première fois lors d'une relance ouvre un nouveau délai de 12 heures. La lecture prudente consiste à faire partir le délai de la première tentative, ce qui veut dire que les relances seules ne sauveront pas une demande manquée de plus d'une heure.

Apple relance-t-elle après un HTTP 400 ?

Oui, d'après la documentation. Apple cite les 40x et 50x comme codes qui déclenchent une relance. En mars 2026, un développeur a signalé sur les forums d'Apple que les relances après des réponses 400 semblaient s'arrêter, puis a indiqué que les livraisons avaient repris un ou deux jours plus tard, et Apple a demandé un rapport via Feedback Assistant. Prenez le comportement documenté comme règle et votre propre supervision comme preuve.

Récupérer les notifications App Store manquées avec Get Notification History

Get Notification History renvoie les notifications de version 2 qu'Apple a tenté d'envoyer à votre serveur sur la période que vous choisissez. Chaque enregistrement contient le payload signé complet, que vous pouvez donc passer au même handler qu'une notification en direct. Chaque enregistrement inclut aussi un tableau sendAttempts de six entrées au plus, une pour le premier essai et une pour chacune des cinq relances.

• startDate et endDate sont obligatoires, et startDate doit tomber dans les 180 derniers jours en production ou les 30 derniers jours en sandbox.
• Passez onlyFailures à true pour n'obtenir que les notifications qui n'ont pas atteint votre serveur, plus celles qu'Apple relance encore.
• Filtrez par un notificationType, comme CONSUMPTION_REQUEST ou REFUND, ou par un transactionId pour un seul client, mais pas les deux dans la même requête.
• Chaque appel renvoie 20 enregistrements au plus. Continuez à appeler avec le paginationToken tant que hasMore vaut true, et envoyez chaque fois le même corps de requête.

Une réserve compte pour les remboursements. Apple indique que les enregistrements de l'historique reflètent l'état d'un achat au moment du premier envoi de la notification, pas l'état actuel. Un REFUND récupéré est donc un fait passé. Avant de révoquer l'accès, vérifiez l'état actuel avec les endpoints de transaction ou de statut d'abonnement.

Les notifications V1 ne se récupèrent pas ainsi

Get Notification History ne couvre que la version 2. Apple relance les notifications V1 trois fois, 6, 24 et 48 heures après la tentative précédente, et si toutes échouent, il n'y a aucun historique à rejouer. Raison de plus pour passer en V2 toute app encore en V1.

Récupérer les notifications de remboursement Google Play manquées

Le filet de sécurité de Google, c'est Pub/Sub lui-même. Tant que votre abonnement existe, un message que personne n'a acquitté y reste pendant la période de conservation, 7 jours par défaut et jusqu'à 31 jours si vous l'allongez. Quand votre endpoint revient, la livraison reprend. Deux réglages peuvent discrètement annuler cette protection.

• Un sujet de lettres mortes (dead-letter) retire un message de votre abonnement après un nombre défini de tentatives de livraison échouées. La valeur par défaut est 5, et avec la politique de relance par défaut, qui renvoie immédiatement, cinq tentatives peuvent passer vite. Si vous en utilisez un, surveillez-le comme une seconde boîte de réception.
• Un abonnement sans activité d'abonné, comme des connexions ouvertes, des pulls actifs ou des pushs réussis, expire après 31 jours par défaut. Un endpoint qui reste cassé pendant un mois peut perdre l'abonnement lui-même, avec tout ce qui y attendait.

Les remboursements annulés ont un filet de 30 jours

Pour les remboursements déjà effectués, la Voided Purchases API est le filet de secours en pull. Elle liste les achats annulés des 30 derniers jours, jusqu'à 1 000 par page, avec un quota de 6 000 requêtes par jour et 30 requêtes sur toute période de 30 secondes pour chaque app. Passez type 1 pour inclure les abonnements en plus des produits à achat unique. L'exécuter chaque jour rattrape tout remboursement perdu par votre chaîne de notifications, ce qui garde justes les droits d'accès et les chiffres de revenus.

Les examens de rétrofacturation n'en ont pas

Une PendingRefundReviewNotification est différente. Elle porte le pendingRefundToken que vous devez transmettre à orders.reviewrefund, et vous avez 24 heures à partir de sa réception pour envoyer votre préférence de remboursement et vos preuves d'utilisation. Google enregistre votre premier appel et ignore les suivants. La documentation de Google ne décrit aucun endpoint qui liste les examens en attente : si ce message Pub/Sub se perd, vos preuves pour cette rétrofacturation se perdent avec lui.

Ce que coûte une notification de remboursement manquée

Une notification manquée pour un remboursement déjà définitif vous coûte de la comptabilité. Vous la retrouvez plus tard dans la Voided Purchases API ou Get Notification History, vous révoquez l'accès si votre politique le prévoit, et vos rapports se remettent à jour. Agaçant, mais peu coûteux.

Une notification manquée dans l'une des deux procédures contestables coûte de l'argent réel, parce que le store décide sans vos preuves. Chez Apple, la décision de remboursement est alors prise sans vos données de consommation. Sur Google Play, pour les commandes passées après le 3 août 2026, une rétrofacturation perdue vous coûte le prix d'achat moins les frais de service de Play, plus les frais de rétrofacturation facturés par la banque de l'acheteur. Google ne prend en charge que ses propres frais de service.

Et l'argent dépensé pour livrer l'achat était déjà parti avant le début du litige.

• Calcul : temps de GPU et de serveur derrière chaque génération, rendu ou réponse de modèle que l'acheteur a déjà utilisé.
• Appels d'API : requêtes vers des tiers facturées dès leur envoi, souvent à l'appel.
• Stockage : fichiers et médias créés par l'acheteur, toujours sur votre facture d'hébergement.
• Reversements : parts de revenus déjà versées à des créateurs, affiliés ou partenaires sur cette vente.

Rien de tout cela ne revient quand un remboursement passe. Les preuves que vous envoyez pendant ces 12 ou 24 heures sont votre seul levier, et une notification manquée vous le retire.

Une procédure de récupération qui tient la route

• Acquittez d'abord. Stockez le payload brut, renvoyez un code de succès, puis traitez-le dans une file d'attente.
• Interrogez Get Notification History d'Apple avec onlyFailures toutes les quelques minutes pour CONSUMPTION_REQUEST, afin qu'une panne ne coûte que quelques minutes du délai de 12 heures.
• Lancez chaque jour un balayage de Get Notification History avec onlyFailures sur les derniers jours pour tous les types, et rejouez ce que vous trouvez.
• Lancez chaque jour un appel à la Voided Purchases API avec type 1 pour chaque app Google Play, et rapprochez le résultat des remboursements déjà enregistrés.
• Sur Pub/Sub, gardez une conservation des messages de 7 jours ou plus, configurez une alerte sur le sujet de lettres mortes si vous en avez un, et une alerte quand les messages non livrés s'accumulent.
• Testez aussi tout le parcours en production. Le sandbox d'Apple envoie chaque notification une seule fois, sans relance, et Request a Test Notification avec Get Test Notification Status montrent exactement comment votre serveur a répondu.

RefundHalt reçoit pour vous les notifications des deux stores et répond automatiquement aux CONSUMPTION_REQUEST et aux examens de rétrofacturation dans les délais, pour que ce ne soit pas à vous de surveiller l'horloge.