Chaque type d'achat intégré se rembourse différemment, et seuls deux d'entre eux demandent votre version

Le type d'achat intégré que vous avez choisi dans App Store Connect ou la Play Console décide plus que la façon dont le produit est vendu. Il décide comment un remboursement se comporte quand il arrive, si le client peut récupérer l'article gratuitement ensuite, et si l'on vous demande un jour votre version avant que l'argent ne bouge. Un pack de pièces, un déblocage à vie, un abonnement mensuel et un pass de saison ponctuel sont quatre objets juridiques et techniques différents, et les règles de remboursement les traitent ainsi. La plupart des développeurs livrent tous ces produits avec le même code d'achat, puis se demandent pourquoi les remboursements semblent incohérents. Ils ne sont pas incohérents. Ils sont propres à chaque type.

Voici ce qu'est chaque type d'achat intégré, comment un remboursement le frappe, et pourquoi seuls deux des quatre acheminent la décision par votre serveur.

Les quatre types d'achat intégré, et pourquoi les remboursements se divisent selon eux

Apple définit quatre types de produit. Un consommable est épuisé puis racheté : monnaie de jeu, indices, une recharge d'énergie. Un non consommable est acheté une fois et conservé pour toujours : un déblocage pro, une mise à niveau sans publicité, un pack de niveaux téléchargeable. Un abonnement à renouvellement automatique se facture sur un cycle répété jusqu'à ce que le client annule. Un abonnement sans renouvellement accorde l'accès pour une durée fixe qui ne se renouvelle pas d'elle-même, comme une saison de contenu vendue en un seul terme.

Google Play classe le même catalogue différemment mais aboutit au même endroit. Il divise les produits en produits à achat unique et abonnements, et un produit à achat unique est marqué comme consommable ou non selon que votre application le consomme après l'achat. Les mots diffèrent. Les conséquences du remboursement, non.

Les consommables sont le type que la fraude au remboursement vise vraiment

Un consommable est le cas de remboursement le plus difficile que vous rencontrerez, et ce n'est pas un hasard si c'est celui autour duquel Apple a construit la demande de consommation. Au moment où un client achète 10,000 pièces et que votre serveur les lui accorde, la valeur est livrée. S'il dépense ces pièces puis demande un remboursement, la boutique peut lui rendre son argent, mais les pièces ont disparu et ce qu'il vous a coûté de les honorer aussi. Les propres outils d'Apple le reflètent : un consommable quitte l'enregistrement de la transaction une fois terminé et ne porte jamais de date d'annulation, car il n'y a rien de persistant à annuler.

C'est pourquoi le consommable est le type de produit où les preuves paient. Quand un client demande un remboursement sur un consommable, Apple envoie à votre serveur un CONSUMPTION_REQUEST et attend jusqu'à 12 heures un appel Send Consumption Information. Dans cet appel, vous définissez un deliveryStatus et, lorsque vous avez livré, un consumptionPercentage. Le pourcentage est un entier en millièmes de 0 à 100,000, où 100,000 signifie que le client a utilisé la totalité de l'achat. Un solde de pièces que vos registres montrent entièrement dépensé est un 100,000 que vous pouvez signaler, et c'est le fait le plus solide que vous puissiez présenter face à une réclamation d'achat non intentionnel.

Les consommables ne peuvent pas être restaurés, donc le moment est primordial

Parce qu'un consommable ne peut pas être restauré, vous ne pouvez pas le reprendre comme vous pouvez révoquer un abonnement. Une fois un remboursement accordé, votre seule protection est l'enregistrement que vous avez conservé au moment de la vente. Si vous n'avez pas journalisé la livraison et la consommation quand elles ont eu lieu, vous les reconstruisez sous une horloge de 12 heures, ce qui est le pire moment pour partir à la recherche de données. Enregistrez à l'entrée, pas à la sortie.

Les abonnements se remboursent sur une horloge que vous ne contrôlez pas

Les abonnements à renouvellement automatique sont là où la plupart des applications gagnent leur argent, et la mise à jour des remboursements de la WWDC24 les a enfin acheminés par la même fenêtre de preuves que les consommables. Depuis la version 2.11 des App Store Server Notifications, une demande de remboursement sur un abonnement à renouvellement automatique déclenche aussi un CONSUMPTION_REQUEST. Ainsi, les remboursements d'abonnement qui se décidaient auparavant entièrement sans vous arrivent désormais avec une fenêtre de 12 heures attachée.

Le piège est la façon dont la consommation est mesurée. Pour un abonnement à renouvellement automatique, Apple ne veut pas que vous inventiez un pourcentage d'usage. Il calcule la consommation à partir du temps écoulé de lui-même, donc quelqu'un à six mois d'un forfait annuel se lit comme consommé à environ la moitié, quoi que vous envoyiez. Votre levier n'est pas le pourcentage. C'est un refundPreference honnête de GRANT_FULL, GRANT_PRORATED ou DECLINE, appuyé par le signal d'usage que vous détenez réellement. Envoyez la préférence que les preuves soutiennent et laissez Apple la peser.

Les abonnements sans renouvellement se rapprochent d'un déblocage unique

Un abonnement sans renouvellement est un terme fixe que le client achète une fois, et il se comporte davantage comme un non consommable que comme un forfait à renouvellement automatique en matière de remboursement. Apple lui achemine rarement un CONSUMPTION_REQUEST, et il n'y a pas de renouvellement automatique à calculer au prorata. Votre application est responsable du suivi du terme et de sa restauration sur les appareils du client, donc un remboursement signifie mettre fin à une fenêtre d'accès que vous gériez vous-même, pas une qu'Apple chronométrait pour vous.

Les non consommables sont permanents, ce qui coupe des deux côtés

Un non consommable est la chose la plus propre à vendre et un piège silencieux au remboursement. Il est acheté une fois, lié au compte de boutique du client pour toujours, et la boutique peut le restaurer sur n'importe quel appareil à la demande. Cette permanence est un atout jusqu'à ce qu'un remboursement arrive, car vous devez maintenant révoquer un droit dont le compte se souvient encore. Si votre logique de révocation ne vérifie qu'au moment de l'achat et ne revérifie jamais, un client remboursé peut restaurer ses achats et revenir droit dans la fonctionnalité payante.

Google Play ajoute ici un tranchant dur qui piège les nouveaux développeurs. Si votre application ne confirme pas un achat dans les 72 heures, Google le rembourse automatiquement et révoque le droit. Un non consommable que votre code de facturation a oublié de confirmer ne reste pas dans les limbes. Il s'annule de lui-même, et le client perd l'accès à quelque chose qu'il a payé, sans l'avoir demandé.

Qui peut même émettre le remboursement change selon la boutique et le type

Avant de planifier toute réponse à un remboursement, sachez qui tient le stylo. Sur l'App Store, seul Apple peut émettre un remboursement d'achat intégré, pour chaque type de produit. Votre code StoreKit ne peut pas rembourser un achat, et votre support non plus. Vous pouvez envoyer des données de consommation pour influencer la décision d'Apple sur les deux types qui ouvrent une fenêtre, et c'est là tout votre contrôle direct.

Google Play, c'est l'inverse. Vous pouvez rembourser vous-même un produit à achat unique ou une commande d'abonnement depuis la Play Console ou les API Voided Purchases et de remboursement, en totalité ou en partie. Cette liberté est aussi une responsabilité : un remboursement que vous émettez sur un consommable doit quand même révoquer l'article dans votre propre backend, car Google ne sait pas que vos pièces sont dépensées. Le type de produit que vous avez choisi décide de la propreté de cette révocation.

Ce que chaque type de remboursement vous coûte réellement

Le prix remboursé est la ligne que tout le monde surveille et la plus petite partie de la facture. Quand une boutique accorde un remboursement, elle annule sa propre commission avec lui, donc vous perdez votre produit net plutôt que le prix affiché en entier. C'est la bonne nouvelle, et elle s'arrête là. Ce que la boutique rend, c'est la part qu'elle a prise. Ce qu'elle ne rend jamais, c'est ce que vous avez déjà dépensé pour honorer la vente, et ce nombre change fortement selon le type de produit.

Le consommable est le remboursement coûteux

Un consommable remboursé est celui qui peut coûter plus que son prix. Disons qu'un client achète 5,000 crédits qui déclenchent chacun un appel d'inférence payant, en dépense 4,000, puis demande un remboursement. La boutique rend le prix et sa commission, mais le calcul, la facture d'API au jeton, les images que vous avez générées et tout versement à des créateurs que ces crédits ont financé sont tous dépensés. Un remboursement de non consommable ramène au moins un droit sous votre contrôle. Un remboursement de consommable ramène une vente dont vous avez déjà payé le coût entier.

Un rejet de débit est la version plus lourde de la même facture

Un remboursement et un rejet de débit sont des événements différents, et l'écart a maintenant une date. Quand un client conteste le débit auprès de sa banque au lieu de le demander à la boutique, un rejet de débit abouti est définitif du côté de la banque. Pour les commandes Google Play passées le 3 août 2026 ou après, un rejet de débit perdu facture au développeur le prix d'achat moins les frais de service de Play, plus les frais de rejet de débit de la banque, un montant fixe que le réseau de cartes définit. Google Play vous achemine un rejet de débit pour examen via orders.reviewrefund avec une fenêtre de 24 heures, le seul flux de Google qui réclame vos preuves, et il peut tomber sur n'importe quel type de produit.

Comment répondre quand le type décide des règles

Vous ne pouvez pas changer sur quel type de produit un remboursement tombe après la vente, mais vous pouvez cesser de traiter les quatre de la même façon.

• Enregistrez la livraison et la consommation des consommables au moment où elles se produisent. Ce journal est toute votre défense sur le seul type qui ne peut pas être restauré, et la fenêtre de 12 heures est bien trop courte pour le constituer de zéro.
• Revérifiez les droits des non consommables après un remboursement, pas seulement à l'achat. Un appel de restauration doit vérifier l'état actuel, pour qu'un client remboursé ne puisse pas revenir dans la fonctionnalité payante.
• Répondez automatiquement aux deux fenêtres de preuves. Une demande de consommation de 12 heures et un examen de rejet de débit de 24 heures ne peuvent pas attendre que quelqu'un lise une boîte de réception, et ils ne s'étendent pas pour les fuseaux horaires.
• Jugez votre défense de remboursement sur les deux seuls types contestables. Un nombre croissant de remboursements sur des types qui n'ont jamais ouvert de fenêtre est un signal de produit ou de prix, pas un échec de vos preuves.

Rien de tout cela ne consiste à battre la boutique. Il s'agit d'accorder votre réponse à l'objet qui a réellement été vendu. RefundHalt répond au CONSUMPTION_REQUEST du consommable et de l'abonnement et à l'examen orders.reviewrefund de Google Play automatiquement, dans la fenêtre, avec les preuves de livraison et d'usage que vous avez enregistrées au moment de la vente, et il conserve les remboursements qu'aucune fenêtre ne vous a jamais laissé contester dans son propre registre, pour que le nombre par lequel vous vous jugez reste honnête.