Utilisez Google Play RTDN pour une gestion rapide des événements. Utilisez l'API Voided Purchases pour vérifier les commandes annulées et réconcilier vos données. Pour la plupart des applications payantes, le choix le plus sûr est d'utiliser les deux.
Si vous envisagez une défense contre les remboursements Google Play pour vos applications, commencez par cette répartition. L'un des chemins vous indique qu'un changement s'est produit. L'autre permet à votre serveur de récupérer une liste des achats annulés et de vérifier ce qui lui a échappé.
Le choix ne se résume pas vraiment à deux systèmes de notification. Google Play RTDN transmet des messages via Cloud Pub/Sub. L'API Voided Purchases est une API de type pull : c'est votre backend qui l'appelle.
Aucun des deux, à lui seul, n'empêche quiconque de demander un remboursement. Leur valeur réside dans la détection des changements, la vérification des commandes et la garantie que l'accès payant correspond à l'état de l'achat.
Points clés
Utilisez RTDN pour réagir rapidement aux événements liés aux achats et aux abonnements.
Utilisez la liste des achats annulés comme second moyen de vérifier les commandes concernées.
Ne considérez pas un abonnement annulé comme une preuve de remboursement.
Faites en sorte que les deux chemins utilisent la même logique sécurisée de mise à jour des accès.
Traitez séparément l'examen en attente d'une contestation de paiement et une annulation déjà effectuée.
Qu'est-ce que Google Play RTDN ?
Google Play Real-Time Developer Notifications, généralement appelé RTDN, envoie des événements liés aux achats vers un sujet (topic) Cloud Pub/Sub.
Votre backend reçoit un message et le dirige vers le bon worker. Le type de message a son importance. Un renouvellement, une annulation et un achat annulé ne constituent pas le même événement.
Pour le suivi des remboursements, portez une attention particulière à voidedPurchaseNotification. Elle inclut :
purchaseToken : relie l'événement à un achat.
orderId : identifie la commande concernée.
productType : identifie un abonnement ou un achat unique.
refundType : distingue une annulation totale d'un remboursement partiel basé sur la quantité.
La référence RTDN et les définitions des événements de Google expliquent ces champs ainsi que les autres types de notification.
RTDN est utile lorsque vous souhaitez agir rapidement après un changement. Mais un message ne constitue pas l'intégralité de votre base d'achats. Faites-le correspondre aux données enregistrées et récupérez l'état d'achat pertinent si nécessaire avant de modifier l'accès.
Une annulation d'abonnement signifie-t-elle un remboursement ?
Non. Un client peut arrêter les futurs renouvellements tout en conservant l'accès payant jusqu'à la fin de la période en cours.
Ne créez pas de règle qui supprime l'accès dès l'arrivée de SUBSCRIPTION_CANCELED. Vérifiez plutôt l'état de l'abonnement et sa date d'expiration. La révocation et l'expiration nécessitent chacune leur propre traitement.
Qu'est-ce que l'API Voided Purchases ?
L'API Google Play Voided Purchases renvoie une liste des achats annulés, remboursés ou contestés (chargeback) dans la limite de son périmètre pris en charge.
Elle s'applique aux commandes intégrées à usage unique et aux abonnements. Votre serveur peut utiliser les résultats pour vérifier quels achats ne devraient plus donner accès.
La liste peut inclure l'ID de commande, le jeton d'achat, l'heure d'annulation, la source de l'annulation et le motif de l'annulation. Pour les remboursements partiels basés sur la quantité pris en charge, elle peut également inclure la quantité remboursée.
Le guide de l'API Voided Purchases de Google documente une fenêtre de rétrospection de 30 jours. Il ne s'agit pas d'une archive permanente des remboursements. Enregistrez les données traitées dans votre propre système.
Cette API est particulièrement utile après une interruption de worker, un bug de routage ou une lacune dans vos données locales. Elle vous permet également d'effectuer une vérification régulière par rapport aux événements que vous avez traités.
RTDN vs API Voided Purchases : la différence pratique
Question | Google Play RTDN | API Voided Purchases |
Comment cela fonctionne-t-il ? | Google publie un événement vers Pub/Sub. | Votre serveur demande une liste. |
Quel est son rôle principal ? | Traitement rapide des changements d'état d'achat. | Vérification et réconciliation des commandes annulées. |
Couvre-t-elle des événements au-delà des remboursements ? | Oui, y compris les renouvellements et d'autres événements du cycle de vie. | Elle se concentre sur les achats annulés. |
Peut-elle aider après une lacune de traitement ? | La récupération via Pub/Sub dépend de votre configuration et de votre politique de rétention. | Elle peut lister les données disponibles dans la fenêtre de 30 jours. |
A-t-elle besoin d'une protection contre les doublons ? | Oui. | Oui, en particulier lorsque les analyses se chevauchent ou partagent des événements avec RTDN. |
La question clé n'est pas de savoir quel outil est le meilleur pris isolément. C'est plutôt de savoir quelle défaillance chaque outil vous aide à gérer.
RTDN vous offre un chemin rapide. L'API vous offre un chemin de vérification. Votre propre base de données doit réunir les deux.
Lequel votre application devrait-elle utiliser ?
Utilisez RTDN lorsque la rapidité compte
Une application payante ne devrait pas avoir à attendre une analyse planifiée pour détecter un changement d'état d'achat.
Utilisez RTDN lorsque votre application a besoin de mises à jour rapides pour les abonnements, les achats uniques et les commandes annulées. Orientez chaque événement selon son type plutôt que d'appliquer une seule règle de remboursement à tous les messages.
Utilisez l'API lorsque l'exhaustivité compte
Utilisez des vérifications planifiées de l'API pour repérer les commandes annulées que votre worker n'a pas appliquées à vos données.
Par exemple, votre récepteur a pu accepter un message, mais un bug a pu empêcher la mise à jour d'accès qui devait suivre. Corriger uniquement la livraison ne résoudra pas cette lacune locale.
Utilisez les deux pour un workflow de remboursement en production
Pour la plupart des applications payantes, combinez les deux. Faites en sorte que les deux chemins alimentent un gestionnaire commun qui vérifie la commande et applique tout changement en toute sécurité.
Cela réduit le risque qu'un événement manqué laisse l'accès actif. Cela réduit également le risque inverse : supprimer l'accès deux fois pour le même remboursement.
Comment détecter les remboursements Google Play étape par étape
1. Tenez un registre des achats
Enregistrez le package de l'application, le jeton d'achat, l'ID de commande, le produit, la correspondance avec l'utilisateur et la quantité accordée. Un registre est simplement un relevé clair de ce qui a été acheté et de l'accès que cela a accordé.
Pour les abonnements, enregistrez également les ID de commande des renouvellements. La référence RTDN précise que chaque renouvellement automatique génère un nouvel ID de commande. Un jeton d'achat seul ne suffit pas pour identifier chaque renouvellement concerné.
2. Sécurisez et orientez les messages RTDN
Configurez correctement l'accès à Pub/Sub. Pour la livraison en push, vérifiez la requête authentifiée. Pour la livraison en pull, restreignez qui peut lire l'abonnement.
Décodez le message, vérifiez le nom du package, puis enregistrez-le avant d'exécuter un traitement long. Envoyez des événements de test à travers l'ensemble du chemin, pas uniquement vers le point de réception.
3. Exécutez une analyse planifiée des achats annulés
Appelez la méthode list avec les identifiants appropriés et les autorisations Play Console. Parcourez toutes les pages de résultats.
Deux paramètres de requête sont faciles à manquer :
type=1 inclut à la fois les achats uniques et les abonnements. La valeur par défaut, 0, n'inclut que les achats uniques.
includeQuantityBasedPartialRefund=true inclut les remboursements partiels basés sur la quantité pris en charge. Sa valeur par défaut est false.
La référence de la méthode voidedpurchases.list de Google décrit les champs de requête et de pagination.
Utilisez un léger chevauchement entre les analyses et dédupliquez les résultats. Choisissez la fréquence des analyses en fonction de votre volume, de vos quotas et du délai que votre application peut accepter. N'attendez pas que la fenêtre de rétrospection soit presque écoulée.
4. Appliquez chaque changement une seule fois
Les deux chemins peuvent signaler la même annulation. Mettez en place un traitement idempotent : réappliquer le même changement ne doit pas modifier le résultat.
N'utilisez pas l'ID de commande seul pour écarter tout événement ultérieur. Un achat à quantité multiple peut faire l'objet de plusieurs remboursements partiels. Suivez les ajustements traités et les quantités remboursées afin qu'un remboursement ultérieur réel ne soit pas perdu.
5. Surveillez l'écart, pas seulement le nombre de messages
Suivez la dernière analyse réussie, les pages inachevées, les erreurs de worker et les commandes non appariées. Mesurez le temps nécessaire pour mettre à jour l'accès après un événement confirmé.
Pour un reporting plus large, consultez notre guide des outils de suivi des remboursements et des contestations de paiement pour applications mobiles.
Exemple : un remboursement, deux chemins de détection
Il s'agit d'un scénario hypothétique, pas d'un cas client rapporté.
Un joueur achète un pack à usage unique qui accorde 500 pièces. L'achat est ensuite entièrement annulé.
RTDN envoie un message d'achat annulé. Votre worker retrouve la commande, vérifie l'octroi enregistré et applique votre politique publiée aux pièces liées à cet achat.
Plus tard, l'analyse planifiée de l'API renvoie la même commande. Le gestionnaire commun constate que l'ajustement lié à l'annulation totale a déjà été appliqué. Il enregistre la correspondance et n'effectue aucune seconde déduction.
Supposons maintenant que le worker ait échoué avant d'appliquer le premier changement. L'analyse retrouve la commande et offre à votre système un autre moyen de la traiter.
C'est tout l'intérêt d'utiliser les deux. Pas deux sanctions distinctes, mais deux moyens d'atteindre un seul résultat correct.
Si certaines pièces ont déjà été dépensées, ne retirez pas aveuglément des pièces d'un pack payant sans lien avec l'achat. Appliquez une politique claire, expliquez l'action et proposez une voie de support.
L'examen en attente d'un remboursement est un workflow distinct
La documentation actuelle de Google mentionne également pendingRefundReviewNotification pour une demande de contestation de paiement nécessitant un examen par le développeur.
Pour cet événement, Google indique de fournir une suggestion de remboursement et des preuves d'utilisation de l'achat via orders.reviewrefund dans un délai de 24 heures.
Ne la confondez pas avec voidedPurchaseNotification. L'une concerne un examen en attente. L'autre signale un achat qui a été annulé.
L'API Voided Purchases ne remplace pas la gestion d'un événement d'examen en attente. Gardez cette branche distincte et ne présumez pas que chaque demande de remboursement en déclenche un.
Remboursements App Store et pertes de revenus : ce que les développeurs doivent savoir
Les pertes de revenus ne se limitent pas au fait qu'une boutique rembourse de l'argent. Elles peuvent aussi signifier que votre backend continue d'accorder un accès payant après que l'achat concerné ne le justifie plus.
Pour les équipes présentes sur les deux plateformes, l'objectif est similaire : garder l'argent, l'état des achats et les données d'accès alignés. Les outils de chaque boutique et les règles d'événements sont toutefois différents. Ne copiez pas un workflow Apple vers Google Play sans l'adapter.
Notre guide sur la gestion des revenus liés aux remboursements App Store couvre ce problème de gestion des revenus dans son ensemble. Pour cette intégration Google Play, concentrez-vous d'abord sur les annulations manquées, les déductions en double et les changements incorrects d'accès aux abonnements.
Ce que la prévention de la fraude aux remboursements sur Google Play peut et ne peut pas faire
La prévention de la fraude aux remboursements sur Google Play commence par des données fiables et des règles équitables. Une commande annulée ne prouve pas que le client a agi de manière malhonnête.
Un utilisateur peut avoir une réclamation légitime. Un paiement peut échouer. Votre application peut avoir livré le mauvais article.
Utilisez ces outils pour vérifier les faits et appliquer les changements d'accès. Examinez les schémas récurrents dans leur contexte. Évitez les bannissements automatiques de compte basés sur un seul remboursement, et permettez aux clients de contester les erreurs.
Ni RTDN ni l'API de liste ne garantissent que vous puissiez empêcher, refuser ou annuler un remboursement.
Conclusion
Le choix entre RTDN et l'API Voided Purchases n'est pas une décision exclusive pour la plupart des applications payantes.
Utilisez RTDN pour réagir rapidement. Utilisez des vérifications planifiées des achats annulés pour réconcilier vos données. Faites passer les deux par un gestionnaire sécurisé unique, et gardez les examens en attente séparés des annulations effectuées.
Commencez par un petit test : envoyez une annulation à travers les deux chemins et vérifiez que l'accès ne change qu'une seule fois. Arrêtez ensuite votre worker et vérifiez que votre chemin de récupération comble l'écart.
Questions fréquentes
RTDN est plus adapté à un traitement rapide des événements. L'API est plus adaptée aux vérifications planifiées des commandes annulées. La plupart des applications payantes profitent des deux.
Oui. Elle inclut une notification d'achat annulé avec les détails de la commande et du type de remboursement. Traitez cet événement séparément d'une annulation d'abonnement.
Vous pouvez détecter les données d'annulation disponibles par polling, mais la détection attend votre prochaine analyse réussie. Vous passez également à côté du flux d'événements du cycle de vie plus large de RTDN.
Google documente une fenêtre de 30 jours. Conservez vos propres données pour les vérifications à plus long terme et les besoins de support.
Oui. Activez les résultats de remboursement partiel pris en charge dans les requêtes de liste. Suivez les quantités remboursées et prévoyez la possibilité de plusieurs remboursements partiels sur une même commande.
