Vos données de consommation informent la décision de remboursement d'Apple, elles ne la contrôlent pas

Un client appuie sur remboursement et, en moins d'une minute, votre serveur reçoit une CONSUMPTION_REQUEST d'Apple. Vous avez 12 heures pour répondre avec les données de consommation, et il est tentant de lire cette réponse comme un veto : envoyez préférer refuser, gardez l'argent. Ce n'est pas un veto. La documentation d'Apple elle-même indique que l'App Store utilise divers facteurs pour déterminer si une demande de remboursement est approuvée ou refusée, et que l'information de consommation que vous fournissez sert à informer ses décisions de remboursement. Informer, pas décider. Cet article parcourt ce que vos données de consommation déplacent réellement, pourquoi un achat que vous avez marqué préférer refuser peut tout de même être remboursé, et ce que vaut tout l'exercice une fois que vous comptez l'argent que vous avez déjà dépensé.

Ce qu'Apple fait vraiment de vos données de consommation

Le point de terminaison Send Consumption Information existe pour que vous puissiez fournir à Apple du contexte au moment où un remboursement est en jeu. Il ne vous remet pas la décision. Lire le flux dans le bon ordre, c'est toute la différence entre poser des attentes raisonnables et ouvrir un rapport de bug contre un comportement qui est documenté.

L'App Store décide, et vous recommandez

Apple est explicite sur le partage. Dans la référence de Send Consumption Information, Apple écrit que l'App Store utilise divers facteurs pour déterminer si une demande de remboursement est approuvée ou refusée, et qu'il utilise l'information de consommation que vous fournissez pour informer ses décisions de remboursement. Sur le champ refundPreference lui-même, Apple précise que votre préférence de remboursement est l'un des divers facteurs que l'App Store utilise pour informer ses décisions de remboursement. Ainsi, le signal le plus fort que vous pouvez envoyer, un préférer refuser catégorique, reste une entrée dans un modèle que vous ne contrôlez pas. L'historique du client, le motif qu'il a donné, le type de produit et les propres signaux de fraude d'Apple se trouvent tous dans ce même modèle, à côté de votre réponse.

CONSUMPTION_REQUEST couvre désormais les abonnements, pas seulement les consommables

C'était autrefois une histoire de consommables. Depuis la WWDC24, la notification CONSUMPTION_REQUEST se déclenche quand un client demande un remboursement pour un achat intégré consommable ou un abonnement à renouvellement automatique. C'est une large extension de la surface. La même réponse en 12 heures s'applique désormais aux remboursements d'abonnements, où votre marge de manœuvre est différente parce qu'Apple calcule elle-même la consommation des renouvellements automatiques et n'acceptera pas de préférence au prorata de votre part. Lisez le type de produit sur chaque demande avant de décider avec quelle force votre réponse peut pousser.

Les cinq entrées que vous êtes autorisé à envoyer

Le corps de requête V2 qu'Apple accepte est petit, cinq champs font le travail, et trois d'entre eux sont obligatoires. Chacun est une entrée qu'Apple pondère, pas un interrupteur qui force un résultat. Voici ce que vous pouvez mettre dans la réponse et ce que cela dit à Apple.

La fenêtre de 12 heures, et la barrière de consentement que la plupart des équipes ratent

Deux mécanismes décident si votre réponse compte seulement. L'un est une horloge. L'autre est un indicateur de consentement qui arrête à la porte beaucoup de réponses bien intentionnées.

Répondez dans les 12 heures ou le moment passe

La consigne d'Apple est nette : répondez dans les 12 heures suivant la réception de la notification CONSUMPTION_REQUEST. C'est toute la fenêtre. Une demande de remboursement n'attend pas votre prochain jour ouvrable, et une réponse de consommation qui arrive en retard est une réponse qu'Apple n'a jamais pondérée. Si vous répondez à celles-ci à la main, l'horloge de 12 heures est la partie qui lâche en premier et en silence, les week-ends, les jours fériés et à 3 heures du matin dans votre fuseau horaire. La réponse doit être automatisée pour être fiable, parce que la fenêtre se moque de savoir quand votre équipe est réveillée.

Vous ne pouvez pas envoyer de données à moins que le client ait consenti

Voici la barrière sur laquelle les équipes trébuchent. Apple rejette une demande Send Consumption Information dont la valeur de customerConsented est autre chose que true. Selon les termes d'Apple, si le client a donné son consentement, répondez en appelant l'API et en envoyant les données de consommation ; sinon, ne répondez pas à la notification CONSUMPTION_REQUEST. Apple place aussi la responsabilité entièrement sur vous : vous devez obtenir un consentement valide du client avant de partager ses données personnelles, et vous, le développeur, êtes seul responsable de l'obtenir. La première question sur chaque demande n'est donc pas combien ont-ils utilisé, c'est ce client a-t-il accepté que nous le disions à Apple. Pas de consentement, pas de réponse, et le remboursement est décidé sur tout sauf votre version de l'histoire.

Ce qui fait vraiment bouger la décision de remboursement d'Apple

Si la réponse est une recommandation, la question honnête est de savoir à quel point elle recommande. La réponse, c'est que vos données comptent le plus précisément là où un humain hésiterait, et le moins là où le résultat n'a jamais vraiment fait de doute.

Pourquoi vous pouvez envoyer préférer refuser et voir tout de même un remboursement

Des développeurs rapportent avoir envoyé préférer refuser sur un achat que le client a entièrement consommé et avoir vu Apple le rembourser tout de même. Ce n'est pas une API cassée. Apple vous a dit qu'elle pondère divers facteurs, et sur une demande donnée certains de ces facteurs peuvent l'emporter sur un consommable entièrement consommé : un client au dossier propre, un motif déclaré qu'Apple juge solide, un petit montant, une première demande. Votre réponse a poussé contre le remboursement. D'autres entrées ont poussé plus fort. La leçon n'est pas d'arrêter de répondre, c'est d'arrêter d'attendre qu'un consommable net survive toujours. Là où le signal est vraiment mitigé, un statut partiellement consommé, un problème de livraison documenté et une préférence honnête sont les entrées qui peuvent faire pencher un cas limite en votre faveur.

Ce que vaut une recommandation en dollars

Un remboursement n'est pas le prix de la vente. C'est le prix de la vente plus tout ce que vous avez déjà dépensé pour la livrer, et la réponse de consommation ne touche jamais que la première partie.

L'argent est déjà dépensé au moment où la demande arrive

Au moment où Apple demande s'il faut rembourser, le client a déjà utilisé la chose. Sur un consommable, cela signifie que le calcul a tourné, que les appels aux API tierces ont été facturés, que les images, jetons ou générations ont été produits, et que le stockage a été écrit. Ce sont des coûts payés de votre côté et ils ne reviennent pas si Apple refuse le remboursement, et ils sont perdus deux fois si Apple l'accorde. Votre réponse de consommation peut récupérer le prix de vente sur un cas limite. Elle ne peut pas récupérer le coût des biens que vous avez déjà remis. C'est la vraie raison pour laquelle un achat entièrement consommé est celui qui coûte cher à rembourser, et cela n'a rien à voir avec la date à laquelle il a été acheté.

• Le prix de vente : votre produit net après la commission d'Apple, annulé si le remboursement est accordé. C'est la seule partie que votre réponse peut influencer.
• Le coût de livraison : calcul, appels d'API, stockage et tout versement que vous avez déjà effectué au titre de l'achat. Perdu quelle que soit la décision.
• Le temps du personnel : chaque remboursement traité à la main représente des minutes de la journée d'une personne, et la fenêtre de 12 heures fait tomber ces minutes à des heures peu commodes.
• Le schéma qui vous échappe : un client qui se fait rembourser encore et encore est un coût que vous ne voyez que si vous suivez la consommation et l'historique au fil des demandes, au lieu de traiter chacune comme un cas isolé.

Comment Google Play gère la même question

Apple n'est pas la seule boutique qui vous demande de vous prononcer puis décide elle-même. Google Play mène un flux parallèle pour les rétrofacturations bancaires, et la forme est la même : vous envoyez des preuves, la boutique décide. Les différences sont dans l'horloge et dans ce que vous êtes autorisé à envoyer.

La conclusion pour les deux boutiques est identique. Votre travail est de répondre dans la fenêtre avec des preuves de consommation exactes et une préférence honnête. Le travail de la boutique est de décider. Confondre les deux, c'est ainsi qu'une équipe finit soit par ignorer la fenêtre parce que la réponse n'est qu'une recommandation, soit par se fier à la réponse comme à un veto et se faire surprendre quand un remboursement tombe malgré tout. Aucune des deux n'est juste. Répondez à chaque fois, répondez avec exactitude, et traitez le résultat comme une décision que vous avez informée, pas une que vous avez prise.

RefundHalt capte la CONSUMPTION_REQUEST au moment où Apple l'envoie, vérifie le consentement, assemble le statut de consommation, le statut de livraison et une préférence de remboursement fondée sur des preuves, et répond dans la fenêtre de 12 heures sans que personne dans votre équipe ne surveille une horloge. Il fait de même pour l'examen des rétrofacturations de Google Play dans sa fenêtre de 24 heures. Vous ne pouvez pas faire décider Apple dans votre sens. Vous pouvez faire en sorte qu'Apple ne décide jamais sans votre version de l'histoire, sur chaque remboursement, à temps.