Ne confirmez pas un achat Google Play sous trois jours et Google le rembourse, voici ce que cela vous coûte

Un client achète votre produit, le paiement passe, et trois jours plus tard Google Play le rembourse discrètement et retire ce que vous avez livré. Personne n'a demandé ce remboursement. Le client ne l'a pas sollicité et aucun agent de support ne l'a accordé. Il s'est déclenché parce que votre serveur n'a jamais dit à Google que l'achat était traité. Si vous ne confirmez pas un achat Google Play sous trois jours, Google rembourse l'acheteur et révoque l'achat, à chaque fois. C'est l'un des rares remboursements sur l'une ou l'autre boutique qui dépend entièrement de votre intégration pour être évité, et l'une des façons les plus silencieuses de perdre des revenus.

Ce n'est pas un problème de fraude ni un litige de politique. C'est un rappel manqué. La correction est petite et le coût de son omission est de l'argent réel, il vaut donc la peine de connaître la règle avec exactitude, de comprendre pourquoi les achats passent sans confirmation et ce que chaque vente perdue emporte réellement avec elle.

Ce que dit vraiment la règle des trois jours

La documentation Play Billing de Google est catégorique à ce sujet. Après que votre app a accordé le droit et dit à l'utilisateur que l'achat a réussi, elle doit notifier à Google que l'achat a été traité. Selon les mots de Google, cela "doit être fait sous trois jours pour que l'achat ne soit pas automatiquement remboursé et le droit révoqué". La page du produit unique le répète sans l'adoucir : "Si vous ne confirmez pas un achat sous trois jours, l'utilisateur reçoit automatiquement un remboursement et Google Play révoque l'achat". Les abonnements suivent la règle identique pour l'achat initial.

La confirmation est un signal, pas une formalité. Elle dit à Google que le droit a atteint l'utilisateur. Google traite l'absence de ce signal comme une livraison qui n'a jamais eu lieu, et il annule la transaction au nom du client. Du côté de l'acheteur, cela ressemble à un remboursement gratuit qu'il n'a jamais demandé. De votre côté, cela ressemble à une vente qui s'est évaporée.

Le compte à rebours démarre à PURCHASED, pas au paiement

La fenêtre de trois jours ne commence pas quand l'utilisateur appuie sur acheter. Elle commence quand l'état de l'achat passe à PURCHASED. Un achat peut d'abord rester en PENDING, ce qui arrive avec les paiements en espèces, les virements bancaires lents ou un parent approuvant la demande d'un enfant. Google est explicite : "La fenêtre de confirmation de trois jours ne commence que lorsque l'état de l'achat passe de PENDING à PURCHASED".

Cela a deux conséquences. N'accordez le droit que lorsque l'état est PURCHASED, jamais en PENDING, sinon vous distribuez le produit pour un paiement qui pourrait ne jamais aboutir. Et ne confirmez pas non plus un achat en PENDING. Vous appelez enablePendingPurchases() quand vous construisez le BillingClient, attendez la transition, et seulement alors le compte à rebours de confirmation commence à tourner dans votre tête.

Confirmer ou consommer, et lequel vous incombe

Il y a deux façons de satisfaire l'exigence, et celle que vous utilisez dépend du produit. Les deux respectent le délai de trois jours. La différence est ce qu'elles font d'autre.

Pour un consommable, vous le consommez. Sur un backend sécurisé c'est purchases.products.consume, ou côté client consumeAsync() dans la Play Billing Library. Consommer confirme l'achat et rend en même temps le produit à nouveau achetable, ce qui est exactement ce que vous voulez pour des pièces, des crédits ou une génération unique. Pour un non-consommable ou un abonnement, vous le confirmez : purchases.products.acknowledge ou purchases.subscriptions.acknowledge sur le backend, ou acknowledgePurchase() côté client. Confirmer respecte le délai sans libérer le produit pour un nouvel achat.

Les renouvellements sont déjà gérés, les achats initiaux non

Vous ne devez confirmer que le premier achat d'un abonnement. Google déclare clairement que "vous n'avez pas besoin de confirmer les renouvellements d'abonnement", et il estampille les renouvellements ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED de lui-même. Un nouvel achat arrive comme ACKNOWLEDGEMENT_STATE_PENDING et reste votre responsabilité jusqu'à ce que vous le régliez. Avant de confirmer, vérifiez acknowledgementState sur le backend ou isAcknowledged() côté client pour ne pas confirmer deux fois.

Les forfaits prépayés ont une mèche plus courte

Les forfaits d'abonnement prépayés resserrent la fenêtre. La règle de Google : les forfaits prépayés d'une durée d'une semaine ou plus doivent être confirmés sous trois jours, mais "les forfaits prépayés d'une durée inférieure à une semaine doivent être confirmés dans la moitié de la durée du forfait". Un forfait prépayé de trois jours vous donne un jour et demi, pas trois jours. Si vous vendez des recharges prépayées courtes, votre chemin de confirmation doit être rapide et piloté par le serveur, pas dépendant du fait que l'utilisateur rouvre l'app.

Pourquoi les achats restent sans confirmation en premier lieu

Personne ne cherche à sauter la confirmation. Elle échappe parce que le code qui confirme se trouve au mauvais endroit. L'anti-modèle courant est un client qui ne confirme que lorsque le flux d'achat revient au premier plan. Cela fonctionne pour un utilisateur qui termine son achat et continue à utiliser l'app. Cela échoue pour tous les autres.

Les développeurs se heurtent à cela constamment. Les fils dans la propre communauté de développeurs de Google se lisent de la même façon à chaque fois, une variante de "un utilisateur a été automatiquement remboursé après avoir acheté dans mon app au bout de trois jours" et "pourquoi les paiements sont-ils automatiquement remboursés après trois jours". La réponse est presque toujours la même : l'appel de confirmation ne s'est jamais déclenché parce que l'app n'a jamais été dans un état pour le déclencher.

L'essai gratuit et l'utilisateur qui ne revient jamais

La pire version est l'essai gratuit ou un achat juste avant que l'utilisateur ne ferme l'app pour de bon. Si votre confirmation dépend de la prochaine ouverture de l'app, et qu'il n'y a pas de prochaine ouverture, l'achat expire. Au troisième jour Google le rembourse et le révoque. Pour un essai qui se serait converti en abonnement payant, vous perdez la première facturation que vous n'avez jamais pu encaisser, plus un droit client qui a disparu silencieusement. Aucun des deux n'apparaît comme un ticket de support. Cela apparaît comme un achat annulé que vous devez aller chercher.

Ce que coûte réellement un remboursement sans confirmation

La ligne du remboursement sous-estime la perte. Quand Google annule la vente, vous rendez le prix, et c'est le chiffre visible. Ce n'est pas la facture entière.

Pensez à un consommable qui déclenche un travail réel à l'instant où il est acheté. Un lot de générations d'images, une série d'appels à l'API d'un fournisseur de modèles, un export vidéo, un paiement à un créateur. Vous avez payé pour ce calcul, ces appels d'API, ce stockage et ces paiements au moment de l'utilisation. Le remboursement rend le prix de vente au client. Il ne vous rend pas la facture du fournisseur. Vous avez livré un coût réel et n'avez rien reçu en retour.

Pour les abonnements et les essais, la perte est la première facturation que vous n'encaissez jamais et la relation client qui s'est terminée avant de commencer. Et à partir du 3 août 2026, Google Play transfère aux développeurs le prix d'achat des rejets de débit et les frais bancaires pour les commandes passées après cette date, ce qui rend toute fuite de revenus évitable digne d'être colmatée maintenant plutôt que plus tard. Un remboursement sans confirmation n'est pas un rejet de débit, mais c'est la même leçon : l'argent que vous avez déjà dépensé n'est pas automatiquement de l'argent que vous conservez.

Comment confirmer un achat Google Play côté serveur

Le modèle fiable retire l'app du chemin critique. Faites-le sur votre backend, piloté par des notifications, pas par le fait que l'utilisateur rouvre l'écran.

• Écoutez les Real-time developer notifications. Un événement d'achat ONE_TIME_PRODUCT ou SUBSCRIPTION_PURCHASED dit à votre serveur qu'un achat existe à l'instant où Google le sait, que l'app soit ouverte ou non.
• Vérifiez le jeton d'achat contre la Play Developer API et confirmez que l'état est PURCHASED, pas PENDING.
• Accordez le droit dans vos propres enregistrements, associé à l'utilisateur.
• Confirmez ou consommez immédiatement. Consommez les consommables, confirmez les non-consommables et les abonnements initiaux. Vérifiez acknowledgementState d'abord pour ne jamais confirmer deux fois.
• Complétez aussi côté client. Appelez queryPurchasesAsync() dans onResume() pour que tout achat terminé pendant que l'app était fermée soit quand même traité. C'est un filet de sécurité, pas le chemin principal.

L'essentiel est que la confirmation se déclenche à partir d'un événement que Google vous envoie, pas d'une action de l'utilisateur sur laquelle vous ne pouvez pas compter. Un utilisateur qui achète et ne revient jamais est entièrement couvert parce que votre serveur a agi à l'instant où l'achat est arrivé.

Un filet de réconciliation pour ceux qui échappent

Même un pipeline propre bénéficie d'une vérification. La Voided Purchases API liste les achats qui ont été remboursés, révoqués ou rejetés, et nomme le cas où la raison est que l'achat "n'a jamais été confirmé par le développeur, et pourrait donc ne pas exister dans les enregistrements du développeur". Interrogez-la et vous pouvez révoquer le droit que vous avez accordé pour tout ce que Google a déjà annulé. Notez la limite : l'API ne renvoie que les achats annulés des 30 derniers jours, la réconciliation doit donc s'exécuter selon un calendrier, pas une fois par trimestre.

Apple n'a pas d'équivalent, et cela compte

C'est un problème spécifique à Google Play. Le StoreKit d'Apple a aussi une étape de finalisation, finaliser une transaction, mais il fait le contraire en cas d'échec. Si vous ne finalisez jamais une transaction StoreKit, Apple la garde dans la file et la réémet chaque fois que votre app se lance ou que l'observateur s'attache, vous avez donc une nouvelle chance d'accorder le droit. Apple ne rembourse pas une transaction non finalisée. Il n'y a pas de remboursement automatique de trois jours sur l'App Store.

Donc le modèle mental doit rester spécifique à chaque plateforme. Sur Google Play, un achat non traité est un remboursement sur le point de se produire et un délai contre lequel vous courez. Sur l'App Store, un achat non traité est une réémission sur le point de se produire et aucun compte à rebours du tout. Porter l'hypothèse d'Apple vers Android est la façon dont les équipes finissent avec un mur de remboursements sans confirmation qu'elles ne peuvent pas expliquer.

C'est pourquoi RefundHalt confirme les achats Google Play automatiquement à l'instant où la notification de la boutique arrive, et les réconcilie contre la Voided Purchases API pour qu'un droit accordé pour un achat que Google a ensuite annulé ne reste pas actif. La règle des trois jours cesse d'être une course que vous pouvez perdre et devient une étape qui a déjà eu lieu.