Il existe un endpoint qui renvoie tout l'historique des remboursements App Store d'un client, et voici ce qu'il retourne

Apple conserve un enregistrement interrogeable de chaque remboursement qu'elle a accordé sur le compte d'un client pour votre app, et un seul appel le renvoie. L'endpoint s'appelle Get Refund History, il fait partie de l'App Store Server API, et il vous remet l'historique complet des remboursements App Store de ce client sous forme de liste de transactions signées. Vous passez un id de transaction, vous récupérez ce qu'Apple a remboursé, et vous le rapprochez de ce que vous avez encore activé.

Voici pourquoi cela en vaut la peine. Un remboursement que vous ne voyez jamais est un remboursement que vous continuez à payer. L'argent est déjà parti, mais le compte reste actif, et chaque heure où il l'est, vous continuez à dépenser en calcul, appels à l'API du modèle, stockage et tout reversement lié à ce client. Vos notifications de remboursement sont censées attraper cela dès que ça se produit. Get Refund History est le filet de sécurité pour quand elles échouent, après une panne, un déploiement qui a perdu un webhook, ou un cas de support où vous avez besoin de la vue d'ensemble en un seul appel.

Ce que renvoie l'endpoint d'historique des remboursements App Store

Vous appelez GET /inApps/v2/refund/lookup/{transactionId} sur l'App Store Server API, signé avec le même JWT que vous utilisez pour tous les autres appels. L'id de transaction dans le chemin peut être n'importe quelle transaction du client. Apple le lit comme une identité, pas comme un filtre, et renvoie les achats remboursés de ce client dans toute votre app : consommables, non consommables, abonnements à renouvellement automatique et non renouvelables sans distinction. L'ancienne V1 de cet endpoint renvoyait jusqu'à 50 remboursements en une seule réponse et est obsolète. La version actuelle pagine, vous gérez donc les clients aux longs historiques sans une charge géante.

La réponse comporte trois champs

Ce qu'une transaction remboursée vous apprend

Chaque entrée de signedTransactions est un JWS. Vérifiez-le contre la chaîne de certificats d'Apple, décodez-le, et vous avez une charge utile de transaction ordinaire avec les champs de remboursement renseignés. Ce sont ceux qui comptent ici.

Le jeton revision est ce qui vous évite de relire toute la liste

La façon naïve d'utiliser cet endpoint est de rechercher un client et de parcourir chaque page à chaque fois. Ça marche, et sur un client avec cinquante remboursements, ce sont cinquante lignes que vous connaissiez déjà plus la seule nouvelle. Le jeton revision existe pour éliminer ce gaspillage. Chaque réponse porte un revision. Quand hasMore est vrai, vous le renvoyez pour obtenir la page suivante. Quand vous atteignez la fin, vous conservez le dernier revision que vous avez vu.

Ce que cet endpoint ne fera pas

Il y a une attente à abandonner avant de construire dessus. Get Refund History fonctionne par client, pas par app. Vous ne pouvez pas lui demander tous les remboursements que votre app a subis la semaine dernière. Il répond à une question, quels remboursements ce compte a-t-il, et vous devez arriver avec un id de transaction de ce compte pour la poser. Les développeurs se heurtent à ce mur en permanence et partent chercher un endpoint de remboursements à l'échelle de l'app qui n'existe pas.

La vue à l'échelle de l'app se trouve ailleurs. Votre flux App Store Server Notifications envoie une notification REFUND au moment où Apple accorde chacune, et Get Notification History vous permet de rejouer ce flux filtré sur les types de remboursement sur une plage de dates. La division est donc nette. Les notifications et leur historique vous donnent le flux à l'échelle de l'app. Get Refund History vous donne la liste faisant autorité d'un compte, à la demande, ce qui est ce que vous voulez à un guichet de support ou après une panne.

Ce qu'un remboursement manqué vous coûte en argent

L'endpoint, c'est la plomberie. La facture est la raison pour laquelle vous posez le tuyau. Chaque remboursement de cette liste est de l'argent déjà rendu, et la seule variable qui reste sous votre contrôle est combien de temps vous continuez à dépenser sur un compte qui ne paie plus.

Vous continuez à payer pour servir un compte remboursé

Le prix d'achat est parti à l'instant où Apple accorde le remboursement. Ce qui continue de tourner, c'est le coût de la livraison. Pour une app qui fait un vrai travail par utilisateur, c'est le calcul, les appels à l'API du modèle, le stockage et tout reversement à un créateur ou un partenaire lié à son usage. Un client remboursé dont vous ne coupez jamais l'accès est un abonnement que vous financez de votre poche. Rapprocher avec Get Refund History et révoquer selon ce que vous trouvez, c'est ainsi que vous coupez ce compteur quand une notification est passée à travers.

Une raison de remboursement de 1 est un rapport de défaut déguisé

revocationReason vous coûte deux fois si vous l'ignorez. Le premier coût est le remboursement lui-même. Le second est chaque remboursement futur dû à la même cause. Quand un produit revient sans cesse avec revocationReason 1, un problème réel ou perçu dans votre app, Apple vous remet un échantillon étiqueté de ce qui pousse les clients à demander leur argent. Suivez la tendance par produit et vous pourrez colmater la fuite au lieu de la payer un remboursement à la fois.

Le détecter tard vaut quand même mieux que de ne pas le détecter

Une rétrofacturation est définitive avec la banque et, sur l'autre store, elle entraîne désormais des frais que le développeur absorbe. Un remboursement App Store, ce n'est pas cela. Il est réglé, mais le droit vous appartient, à révoquer dès que vous le savez. Donc même un remboursement que vous trouvez avec des jours de retard via cet endpoint vaut la peine d'être trouvé. Vous ne pouvez pas récupérer l'argent, mais vous pouvez arrêter la dépense qui tournait encore derrière.

Comment cela s'articule avec les notifications, et avec Google

Voyez les pièces comme un seul système. La notification REFUND est le signal en direct, poussé vers votre serveur au fur et à mesure qu'Apple décide. Get Refund History est la source de vérité en mode pull pour un seul client, l'appel que vous faites quand le push a échoué ou quand une personne a besoin du compte complet sous les yeux. Du côté de Google Play, la forme est la même idée avec des noms différents : une VoidedPurchaseNotification est poussée en temps réel, et la Voided Purchases API est la liste que vous tirez. Les deux stores vous donnent un flux et un registre. L'erreur est de ne se fier qu'au flux, car les flux tombent.

La mise en place à la manière de RefundHalt

La boucle est courte une fois chaque pièce en place. Prenez une notification REFUND comme déclencheur. Rapprochez avec Get Refund History pour qu'un webhook perdu ne laisse jamais un compte remboursé actif. Décodez chaque transaction, rattachez-la par appAccountToken ou transactionId à votre utilisateur, lisez revocationReason pour qu'un remboursement dû à un défaut soit signalé et pas seulement classé, et révoquez le droit exact plutôt que tout le compte. Paginez avec le jeton revision pour lire les nouveaux remboursements, pas les anciens.

C'est la partie que RefundHalt exécute pour vous. Il écoute les notifications de remboursement, se rabat sur Get Refund History quand il lui faut la liste faisant autorité, vérifie chaque transaction signée, révoque l'achat précis, et conserve le revision pour que chaque passage ne lise que ce qui a changé. Vous obtenez l'accès coupé en quelques secondes et un enregistrement propre de qui a été remboursé, pour quoi et pourquoi, sans avoir à monter vous-même le polling et la vérification JWS.