Chaque demande de remboursement Apple s'accompagne désormais d'un motif, et consumptionRequestReason est la façon de le lire

Apple a changé la manière dont les demandes de remboursement arrivent sur votre serveur, et beaucoup de développeurs ne l'ont jamais remarqué. Depuis la mise à jour 2.11 d'App Store Server Notifications annoncée à la WWDC24, chaque notification CONSUMPTION_REQUEST comporte un champ appelé consumptionRequestReason. C'est le motif déclaré par le client lui-même pour réclamer son argent. Une simple chaîne, cinq valeurs possibles, livrée dans la même charge utile à laquelle vous avez déjà douze heures pour répondre.

Le motif de la demande de remboursement Apple ne décide rien à lui seul. Ce qu'il fait, c'est vous indiquer dans laquelle de cinq situations très différentes vous vous trouvez, afin que vous cessiez d'envoyer les mêmes données de consommation génériques à un remboursement que vous devriez accorder et à un remboursement que vous devriez contester. Voici ce qu'est ce champ, les valeurs exactes qu'Apple peut envoyer, ce que chacune signale, et comment elle devrait changer la préférence et les preuves que vous renvoyez.

Ce qu'est réellement consumptionRequestReason

consumptionRequestReason est un champ de type chaîne dans l'objet data d'une notification CONSUMPTION_REQUEST. Apple l'a ajouté dans la version 2.11 d'App Store Server Notifications, en même temps que les changements de la WWDC24 apportés au flux de remboursement. Auparavant, la demande arrivait avec la transaction signée et rien sur le motif. Vous répondiez à l'aveugle. Désormais, le motif déclaré par le client voyage avec la demande.

Lisez attentivement le mot déclaré. C'est le motif que le client a sélectionné lorsqu'il a déposé sa demande auprès d'Apple, pas un fait qu'Apple a vérifié. UNINTENDED_PURCHASE ne prouve pas que l'achat est resté inutilisé, et UNSATISFIED_WITH_PURCHASE ne prouve pas que le produit était défectueux. La valeur est un prisme, pas un verdict. Vous l'associez toujours à vos propres registres de livraison et d'usage.

Il voyage dans la notification que vous traitez déjà

CONSUMPTION_REQUEST est le seul flux d'Apple qui demande des preuves au développeur. Son équivalent sur Google Play est l'examen de rétrofacturation via orders.reviewrefund. Lorsqu'une arrive, vous avez 12 hours pour répondre en appelant Send Consumption Information, un PUT vers le point de terminaison de consommation des transactions. consumptionRequestReason fait désormais partie de cette même notification, il n'y a donc rien de nouveau auquel s'abonner. Si vous analysez déjà CONSUMPTION_REQUEST, le motif est un champ que vous ignoriez probablement.

Les cinq motifs, et ce que chacun vous dit

Apple documente exactement cinq valeurs. Une seule arrive par demande. Voici l'ensemble complet et comment lire chacune en pratique.

UNINTENDED_PURCHASE est la catégorie de la pression accidentelle

C'est le motif qu'un parent sélectionne après qu'un enfant a acheté 10,000 pièces, ou un adulte qui a effleuré par erreur un bouton de confirmation. Il est corrélé aux achats qui n'ont jamais été ouverts ni utilisés. C'est précisément pourquoi vos propres données comptent. Si vos registres montrent que le consommable a été entièrement livré et largement consommé, une réclamation d'achat non intentionnel et un solde entièrement dépensé ne concordent pas, et cet écart vaut la peine d'être signalé via consumptionPercentage.

FULFILLMENT_ISSUE renvoie vers vous

FULFILLMENT_ISSUE est le seul motif qui concerne en partie votre application, et non le client. Il signifie qu'il dit ne pas avoir pu recevoir ou utiliser ce qu'il a payé. Avant de contester par réflexe, sortez vos journaux de livraison. Si votre propre serveur montre que le droit n'a jamais été activé, ou que les crédits n'ont jamais été crédités, le client a raison, et DECLINE est la mauvaise préférence. Se battre contre un véritable échec de livraison gaspille la fenêtre et peut pousser le client vers sa banque, où une rétrofacturation coûte plus cher que ne l'aurait fait le remboursement.

UNSATISFIED_WITH_PURCHASE est là où les preuves décident

C'est le remords ordinaire de l'acheteur, et c'est le motif où vos données de consommation font le plus de travail. Le produit a fonctionné. Le client en a utilisé une partie ou la totalité et veut maintenant récupérer son argent. Un consumptionPercentage élevé, un deliveryStatus honnête de DELIVERED et un refundPreference de DECLINE ou GRANT_PRORATED, c'est le dossier qu'Apple vous demande de présenter. Envoyez les chiffres, pas un argument.

LEGAL et OTHER

LEGAL signifie que le client a invoqué un droit légal ou réglementaire. Les gens raisonnables ne sont pas d'accord, mais en règle générale ce n'est pas la fenêtre pour plaider. Accordez-le et passez à autre chose. OTHER est le fourre-tout qu'Apple utilise lorsque le motif déclaré ne correspond à aucun des quatre ci-dessus. Il ne porte aucun signal en soi, alors traitez un OTHER exactement comme vous traiteriez une demande sans motif du tout : commencez par votre statut de livraison et vos preuves d'usage.

Comment le motif change votre réponse, champ par champ

Vous répondez à un CONSUMPTION_REQUEST en appelant Send Consumption Information avec un corps ConsumptionRequest. Le motif devrait façonner trois champs de ce corps.

customerConsented doit être true

Apple n'accepte la soumission que lorsque customerConsented est true, ce qui signifie que le client a accepté de partager les données de consommation. Si vous n'avez pas ce consentement, vous ne pouvez envoyer aucune donnée, quel que soit le motif. Pas de consentement, pas de preuves, et la demande est tranchée sans vos chiffres.

deliveryStatus et consumptionPercentage portent les faits

deliveryStatus indique si vous avez livré un achat fonctionnel. S'il vaut autre chose que DELIVERED, Apple exige que consumptionPercentage soit 0. Lorsque vous avez bien livré, consumptionPercentage est un entier en milliunits de 0 à 100,000, où 100,000 signifie que le client a utilisé l'achat entier. Cette paire est votre socle factuel, et c'est elle qui devrait porter un dossier FULFILLMENT_ISSUE ou UNSATISFIED_WITH_PURCHASE, pas le motif lui-même.

refundPreference est votre seul levier

refundPreference est l'endroit où vous déclarez ce que vous voulez. Apple documente trois valeurs : GRANT_FULL, GRANT_PRORATED et DECLINE. Lisez le motif, pesez-le face à vos données, puis choisissez. Un FULFILLMENT_ISSUE avec une livraison en échec dans vos journaux penche vers GRANT_FULL. Un UNSATISFIED_WITH_PURCHASE sur un produit entièrement consommé penche vers DECLINE ou GRANT_PRORATED. LEGAL penche vers GRANT_FULL.

Ce qu'un remboursement vous coûte réellement

Le champ du motif compte parce qu'un remboursement n'est que rarement la seule vente qui sort de votre comptabilité. Pour un consommable déjà écoulé, vous avez payé pour l'honorer. Un pack de crédits qui a appelé une API d'inférence payante, un lot d'images générées qui a brûlé du temps de GPU, un export stocké qui pèse sur votre facture de stockage, un paiement à un créateur que vous avez déjà envoyé : ces coûts restent dépensés lorsque l'achat est annulé. La boutique rend l'argent du client. Elle ne vous rend pas votre calcul.

C'est pourquoi le motif vaut la peine d'être lu. Supposons qu'un client ait acheté 5,000 crédits qui déclenchent chacun un appel d'API payant, en ait dépensé 4,000, puis ait déposé sa demande sous UNSATISFIED_WITH_PURCHASE. Votre deliveryStatus est DELIVERED, votre consumptionPercentage est de 80,000 milliunits, et une préférence DECLINE ou GRANT_PRORATED fait la différence entre encaisser la facture d'API et en récupérer la majeure partie. Inversez maintenant le motif en FULFILLMENT_ISSUE avec des journaux montrant que les crédits n'ont jamais été crédités, et le geste honnête et le moins coûteux est GRANT_FULL avant que le client n'escalade vers sa banque.

Lire le motif sans réagir de façon excessive

Le piège est de traiter le motif comme une preuve. UNINTENDED_PURCHASE n'est pas un aveu que le produit est resté inutilisé, et LEGAL n'est pas toujours une véritable réclamation légale. Le motif resserre la situation. Vos journaux de livraison et vos registres de consommation la résolvent. Lorsqu'ils concordent avec le client, accordez tôt et à moindre coût. Lorsqu'ils contredisent le client, cette contradiction, exprimée sous forme de deliveryStatus et de consumptionPercentage, est la chose la plus forte que vous puissiez envoyer. RefundHalt lit consumptionRequestReason sur chaque CONSUMPTION_REQUEST et l'associe automatiquement à vos données d'usage réelles, afin que chaque motif reçoive la réponse qu'il mérite dans la fenêtre de 12 hours.

Le changement est petit et facile à manquer, mais il a fait pencher la conversation sur le remboursement en votre faveur. Apple vous dit désormais pourquoi, avant que vous ne répondiez. Servez-vous-en.