Réponse rapide : Google Play vous propose deux moyens de savoir qu'un achat a été remboursé ou révoqué. Les Real-time Developer Notifications (RTDN) envoient des événements à votre serveur dès qu'ils se produisent, via Google Cloud Pub/Sub. La Voided Purchases API vous permet d'extraire une liste des achats annulés à la demande. Ce ne sont pas des alternatives : RTDN vous apporte la rapidité, la Voided Purchases API vous apporte un filet de sécurité, et une configuration fiable utilise les deux pour que rien ne vous échappe.
Pourquoi Google vous propose deux mécanismes
Sur Google Play, la plupart des remboursements se font sans vous demander votre avis : Google les émet, révoque le droit d'accès, et votre rôle consiste à en être informé pour que votre application et vos analyses restent exactes. (Pour savoir ce que vous pouvez contester ou non, consultez Google Play Refunds & Chargebacks.)
Google propose deux outils différents pour vous en informer, et ils résolvent le problème dans des directions opposées. L'un vous envoie des événements au fur et à mesure qu'ils se produisent. L'autre vous permet de demander une liste quand vous le souhaitez. Utilisés ensemble, ils compensent leurs faiblesses respectives ; utilisés seuls, chacun présente une lacune.
Pour les développeurs concentrés sur le suivi des remboursements Android, comprendre cette différence est important, car un flux d'événements en temps réel et un mécanisme de rapprochement historique résolvent des aspects différents du problème de suivi des remboursements.
Real-time Developer Notifications (push)
Real-time Developer Notifications (RTDN) est le mécanisme push. Lorsqu'un événement affecte un abonnement ou un achat, y compris les remboursements et les achats annulés, Google publie un événement sur un topic Google Cloud Pub/Sub auquel votre backend est abonné. L'idée, c'est l'immédiateté : vous êtes informé de l'événement presque au moment où il se produit, plutôt que de le découvrir des heures plus tard.
Pour les développeurs qui recherchent l'intégration RTDN Google Play, c'est le mécanisme qui connecte les événements de facturation Google Play à votre backend. Pour tout ce qui est sensible au facteur temps, comme une révision de rétrofacturation, où vous disposez d'environ 24 heures pour répondre, cette immédiateté est essentielle. Si vous comptez sur des vérifications périodiques, vous avez déjà perdu un temps que vous n'aviez pas.
Le hic : RTDN fonctionne sur Pub/Sub, ce qui implique la configuration d'un projet Google Cloud, un topic, les bonnes autorisations de publication pour Google Play, et un abonné de votre côté. Cela représente plus de composants qu'un simple webhook, et c'est là que beaucoup de développeurs se bloquent.
La Voided Purchases API (pull)
La Google Play Voided Purchases API est le mécanisme pull. Elle renvoie une liste des commandes qui ont été annulées, remboursées, rétrofacturées ou révoquées, que vous pouvez interroger à la demande. Plutôt que d'attendre un événement, vous demandez directement à Google : qu'est-ce qui a été annulé ?
Sa force réside dans l'exhaustivité et la récupération. Si une notification push a été retardée, manquée ou jamais traitée, une requête pull vers la Google Play Voided Purchases API fait tout de même apparaître l'achat annulé. C'est ainsi que vous effectuez le rapprochement et vous assurez que vos données correspondent à celles de Google.
La contrepartie, c'est qu'elle n'est pas instantanée par nature : c'est quelque chose que vous interrogez, donc utilisée seule, elle fait office de filet de sécurité plutôt que de déclencheur.
Pourquoi vous avez besoin des deux, pas d'un seul
Voici la nuance qui piège souvent les gens : il ne s'agit pas de choisir « le meilleur des deux ».
RTDN seul vous apporte la rapidité mais aucune garantie d'exhaustivité : si vous manquez ou mal traitez une notification, cet événement disparaît tout simplement de votre champ de vision.
La Voided Purchases API seule vous apporte l'exhaustivité mais pas la rapidité : vous ne découvririez un remboursement qu'à la prochaine fois où vous interrogez l'API.
RTDN Google Play fournit à votre backend un signal en temps réel, tandis que la Google Play Voided Purchases API assure la couche de rapprochement pour les événements manqués ou retardés.
Une configuration fiable utilise RTDN comme déclencheur en temps réel et la Voided Purchases API comme couche de rapprochement qui rattrape tout ce que le canal push a laissé échapper. La rapidité, plus un filet de sécurité. Chacune utilisée seule laisse une brèche dans laquelle vous finirez par tomber.
Là où ça se complique
Mettre tout cela en place correctement est plus complexe qu'il n'y paraît, et l'effort est continu plutôt que ponctuel :
Provisionnement Pub/Sub. Créer le topic, accorder à Google Play le droit de publier, abonner votre backend, et obtenir des autorisations exactement correctes, c'est l'étape qui risque le plus de vous prendre un après-midi, voire trois. Cette configuration Pub/Sub Play Billing doit également rester fiable à mesure que votre infrastructure de facturation se développe.
Deux systèmes à synchroniser. Vous gérez désormais un consommateur push et une tâche planifiée de pull-et-rapprochement, et vous devez vous assurer qu'ils sont cohérents entre eux.
Déduplication et ordonnancement. Le même événement peut vous parvenir plusieurs fois, ou dans le désordre ; votre traitement doit être idempotent.
Rester à jour. Google révise ses API de facturation et ses types d'événements, et votre intégration doit suivre le rythme, sous peine de devenir obsolète en silence.
Notifications de remboursement Google Play. Votre système doit traiter correctement chaque notification de remboursement Google Play pertinente et la relier au bon achat, au bon droit d'accès et à la bonne fiche client.
Pris individuellement, rien de tout cela n'est exotique. Ensemble, c'est une véritable infrastructure à construire et à maintenir, pour le privilège de suivre avec précision des remboursements que vous ne pouvez, de toute façon, pas contester dans la plupart des cas.
Comment cela s'intègre dans la gestion des remboursements
En assemblant les pièces, la gestion des remboursements Google Play se divise en deux volets : intercepter la seule chose que vous pouvez contester (la révision de rétrofacturation) dans son délai, et enregistrer avec précision tout ce que vous ne pouvez pas contester pour que vos droits d'accès et vos analyses restent fiables. Les deux volets dépendent de la solidité de la base RTDN + Voided Purchases.
Pour les équipes qui se demandent comment suivre les remboursements Google Play avec RTDN et la Voided Purchases API, la réponse consiste à utiliser RTDN pour une détection rapide des événements et la Voided Purchases API pour le rapprochement et la récupération. Cela donne à votre backend une vision plus complète des remboursements, des achats annulés et des rétrofacturations.
C'est exactement la couche que RefundSensor gère pour vous. Il provisionne automatiquement le topic Pub/Sub afin que vous n'ayez qu'à coller un seul nom de topic dans Play Console, consomme RTDN en temps réel, effectue le rapprochement avec les achats annulés pour que rien ne vous échappe, soumet une recommandation de refus sur les révisions de rétrofacturation dans le délai imparti, et enregistre tous les autres remboursements, tout cela dans un seul dashboard, aux côtés de vos remboursements Apple. Vous obtenez le résultat d'une configuration à deux mécanismes correcte sans avoir à construire ni à maintenir l'un ou l'autre de ces mécanismes.
Sources officielles {#official-sources}
Les API de facturation de Google évoluent, considérez donc sa documentation comme la référence ultime :
Une seule configuration, deux mécanismes, zéro maintenance. RefundSensor provisionne automatiquement Pub/Sub, consomme RTDN en temps réel, effectue le rapprochement avec les achats annulés, et gère les révisions de rétrofacturation pour Google Play et Apple, dans un seul dashboard. Commencer gratuitement →
Liens internes à ajouter après publication : Google Play refunds cornerstone · Apple refund automation cornerstone · la fenêtre de 12 heures.
Questions fréquentes
RTDN envoie des événements à votre serveur en temps réel via Pub/Sub ; la Voided Purchases API vous permet d'extraire à la demande une liste des commandes annulées. RTDN apporte la rapidité, la Voided Purchases API apporte l'exhaustivité.
Pour une configuration fiable, oui. RTDN est votre déclencheur en temps réel et la Voided Purchases API est votre filet de sécurité de rapprochement pour tout ce que le canal push a manqué. Chacune utilisée seule laisse une lacune.
Une commande qui n'est plus valide, généralement en raison d'un remboursement, d'une rétrofacturation ou d'une révocation. Suivre les achats annulés permet de garder vos droits d'accès et vos analyses exacts.
RTDN fonctionne sur Google Cloud Pub/Sub, ce qui implique un topic, des autorisations de publication pour Google Play et un abonné de votre côté, soit davantage de composants que de simplement coller une seule URL. RefundSensor provisionne automatiquement le topic Pub/Sub pour supprimer cette friction.
Dans la plupart des cas, non. Les remboursements et révocations ordinaires sont décidés par Google. Le seul cas contestable est une rétrofacturation en cours de révision, que vous devez détecter via RTDN et à laquelle vous devez répondre dans son délai d'environ 24 heures.
