L'envoi des informations de consommation d'Apple demande maintenant cinq champs, pas douze, et voici chacun d'eux

La liste des faits qu'Apple vous demande quand un client veut un remboursement est devenue bien plus courte. La charge Send Consumption Information, la seule réponse qu'un développeur peut apporter à une décision de remboursement de l'App Store, avait autrefois douze champs. Elle en a maintenant cinq. Apple l'a allégée autour de la WWDC24 et a condensé la plupart des anciennes questions de profilage de compte en deux questions simples et un nombre. Moins de champs n'est pas une petite modification. Cela change quelles preuves Apple pèse et cela change quels champs vous ne pouvez pas vous permettre de rater.

Voici pourquoi cela mérite votre attention et n'est pas juste une note sur le schéma. Cette charge est le seul moment dans un remboursement Apple où votre version de l'histoire atteint la décision. Un remboursement de consommable annule des revenus que vous avez déjà dépensé de l'argent réel pour livrer, et les cinq champs sont la façon dont vous dites à Apple que le produit a été livré et utilisé. Manquez la fenêtre de 12 heures ou remplissez mal un champ, et Apple tranche sur la seule réclamation du client.

Ce qu'est Send Consumption Information

Send Consumption Information est le endpoint de l'App Store Server API que vous appelez après qu'Apple a envoyé à votre serveur une notification CONSUMPTION_REQUEST. Cette notification signifie qu'un client a demandé à Apple un remboursement sur un achat intégré et qu'Apple veut votre contribution avant de décider. Vous répondez en envoyant avec un PUT un petit corps JSON, le ConsumptionRequest, vers le endpoint. Apple le lit, le pèse face à l'historique du client et prend la décision. Vous ne décidez jamais du remboursement. Vous fournissez des faits.

Le corps est toute l'interface. Il n'y a pas de formulaire séparé, pas d'appel, pas de second envoi qui compte. Ce que vous envoyez dans cette unique charge est votre dossier complet, donc le sens de chaque champ importe plus que le nombre de champs ne le suggère.

Les cinq champs qu'Apple demande maintenant

Le ConsumptionRequest actuel a cinq membres. Trois sont obligatoires et deux sont facultatifs. Tout ce qu'Apple demandait autrefois sur le compte du client, son ancienneté, ses dépenses cumulées, ses remboursements cumulés, son temps de jeu, a été retiré de ce que vous envoyez.

customerConsented est la barrière

customerConsented est un booléen, et c'est le champ qui décide si vous envoyez quoi que ce soit. Il enregistre si le client a accepté que vous partagiez les données de consommation avec Apple. La consigne d'Apple est directe : si le client n'a pas consenti, n'envoyez pas les informations de consommation. Ce n'est donc pas un champ que vous mettez à true pour renforcer votre dossier. Il reflète un oui ou non réel que vous devez déjà détenir, et un false ici signifie que le reste de la charge ne doit pas être envoyé.

deliveryStatus est le champ qui fait bouger les remboursements

deliveryStatus est un enum de chaîne, et c'est le levier le plus fort dont vous disposez. Il dit à Apple si votre app a réellement livré un achat intégré fonctionnel. Une valeur dit oui. Les quatre autres disent non, chacune pour une raison différente, et chacune dit à Apple que le client a un grief légitime.

sampleContentProvided répond à une question d'équité

sampleContentProvided est un booléen. Il enregistre si vous avez donné au client un échantillon gratuit, un essai ou une information claire sur ce que fait l'achat avant qu'il n'achète. Un true ici est un petit signal d'équité : le client a eu la chance de savoir ce qu'il achetait. Il ne décide rien à lui seul, mais c'est l'un des trois seuls champs obligatoires, donc Apple le veut clairement dans chaque réponse.

consumptionPercentage est maintenant un nombre, pas un statut

C'est le champ qui a le plus changé. L'ancienne charge avait consumptionStatus, un enum à quatre paliers : UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. La nouvelle charge le remplace par consumptionPercentage, un entier mesuré en milliunits. 100,000 milliunits signifie que l'article a été entièrement consommé, donc 50,000 c'est la moitié et 0 c'est intact. Un nombre précis vaut mieux qu'un panier à quatre choix, car il vous permet de dire qu'un client a brûlé 90 pour cent d'un pack de crédits plutôt que d'arrondir vers le bas à partiellement consommé.

Une réserve qui déroute les gens. Pour les abonnements à renouvellement automatique Apple calcule la consommation elle-même à partir du temps écoulé, donc consumptionPercentage est destiné aux achats consommables et non renouvelables. Envoyez-le là où il s'applique, et laissez Apple le dériver là où il ne s'applique pas.

refundPreference exprime une préférence, pas un verdict

refundPreference est une chaîne facultative, et c'est là que vous dites à Apple quel résultat vous préféreriez. Il a aussi changé de forme. L'ancien champ était un nombre avec des valeurs comme prefer-grant, prefer-decline et no-preference. Le nouveau est une chaîne nommée à trois valeurs.

Ce qu'Apple a supprimé, et pourquoi cela compte

L'ancien ConsumptionRequest avait douze champs. Sept d'entre eux ont disparu de ce que vous envoyez. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform et appAccountToken étaient la moitié profilage de compte de la charge, les champs qui vous demandaient de classer un client selon depuis combien de temps il avait un compte, combien il avait dépensé, combien on l'avait remboursé et depuis combien de temps il utilisait l'app.

Apple les a supprimés pour une raison qui mérite d'être notée. Ces champs demandaient aux développeurs de livrer un profil du client, et la plupart des développeurs soit les laissaient non déclarés soit les devinaient. Les cinq qui restent portent sur l'achat et la livraison, des faits que vous pouvez réellement vérifier depuis vos propres systèmes. Le glissement va de qui est le client à ce qui s'est passé avec cet achat précis.

Le endpoint et l'horloge

Vous envoyez la charge avec un PUT HTTP vers le endpoint Send Consumption Information, identifié par l'id de la transaction de l'achat en litige : PUT /inApps/v1/transactions/consumption/{transactionId}. Un succès renvoie 202 Accepted, et le corps de la réponse est vide. Cette réponse vide est attendue, pas un bug. Elle confirme qu'Apple a mis vos données en file, et ne vous dit rien sur le résultat final, qui arrive plus tard sous forme de notification REFUND ou REFUND_DECLINED.

L'horloge est la partie que vous ne pouvez pas étirer. Apple vous donne 12 heures à partir du CONSUMPTION_REQUEST pour répondre. Seule votre première réponse est utilisée, donc la première charge doit être la complète et correcte. Apple peut envoyer le CONSUMPTION_REQUEST plus d'une fois pour le même achat, mais le délai de chacun est fixe, et une revue manuelle tient rarement dans 12 heures entre fuseaux horaires et week-ends.

Ce que coûte un champ mal géré

L'argent a quitté les lieux avant le remboursement

Le remboursement d'un consommable n'est pas une annulation propre. Au moment où un client réclame son argent sur un pack de crédits ou un lot de générations d'IA, vous avez déjà dépensé pour le livrer : inférence GPU sur chaque requête, appels à des API de modèles tiers facturés au token, stockage de ce que vous avez produit, et tout versement aux créateurs ou partenaires lié à cet usage. Le prix de la boutique revient au client. Votre coût de livraison ne vous revient pas. Donc un remboursement que vous auriez pu contester n'est pas un événement à l'équilibre, c'est une perte nette de tout ce que vous avez payé pour servir le compte.

Les cinq champs sont la façon d'éviter de payer deux fois

deliveryStatus réglé sur DELIVERED et un consumptionPercentage élevé sont les deux faits qui disent à Apple que le client a reçu et utilisé le produit. Ils sont votre preuve que le calcul, les appels d'API et le stockage ont tous fait leur travail. Laissez la charge non envoyée et Apple n'en entend jamais parler. Elle décide à partir de la réclamation du client, le remboursement passe plus probablement, et vous encaissez à la fois les revenus annulés et le coût de livraison derrière.

Les rétrofacturations sont la pire porte, et le silence y mène

Un client qui n'obtient pas satisfaction via le flux de remboursement d'Apple peut encore contester la charge auprès de sa banque. Une rétrofacturation de carte est définitive, elle porte des frais de litige fixes, et elle retire la décision des mains d'Apple et des vôtres. Bien répondre au CONSUMPTION_REQUEST maintient le litige dans le système d'Apple, où vous avez voix au chapitre. L'ignorer pousse les cas limites vers le seul canal où vous n'en avez aucune.

Comment RefundHalt gère cela

Les cinq champs semblent simples jusqu'à ce que vous deviez les remplir correctement, en 12 heures, à chaque CONSUMPTION_REQUEST, rattachés à la bonne transaction. RefundHalt capte la notification, lit vos propres relevés de livraison et d'usage pour cet achat, et envoie la charge automatiquement avant que la fenêtre ne se ferme. deliveryStatus reflète ce que vos journaux montrent réellement, consumptionPercentage vient d'un usage réel plutôt que d'une supposition, et refundPreference suit la politique que vous avez configurée une fois. Vous obtenez le remboursement contestable examiné avec des preuves, pas un délai manqué et une décision prise sans vous.