Un remboursement via l'Advanced Commerce API est le seul moyen pour un développeur iOS de lancer un remboursement, et Apple garde le dernier mot

Un développeur iOS ordinaire ne peut pas rembourser un client. En juin 2026, un App Store Commerce Engineer a répondu à une question sur le forum des développeurs en une seule phrase : pour l'instant, un développeur ne peut pas émettre directement un remboursement. Il existe une exception, et elle se trouve dans l'Advanced Commerce API. Les apps qu'Apple approuve peuvent envoyer une demande de remboursement via l'Advanced Commerce API, révoquer un abonnement avec remboursement ou demander un montant personnalisé. C'est toujours Apple qui décide si l'argent est rendu.

Ce qu'est l'Advanced Commerce API et qui y a accès

Apple a lancé l'Advanced Commerce API le 23 janvier 2025. Elle gère les achats intégrés Apple pour des catalogues exceptionnellement vastes d'achats ponctuels personnalisés, d'abonnements et d'abonnements avec options complémentaires. Vous ne créez pas chaque produit dans App Store Connect. Vous définissez les SKU sur votre propre serveur et les transmettez à Apple au moment de l'achat.

L'accès est accordé app par app. Vous remplissez un formulaire de demande, et la page d'éligibilité d'Apple cite trois modèles économiques qui doivent être au cœur de l'app :

• Des catalogues exceptionnellement vastes d'achats ponctuels, comme des livres audio, des leçons, des cours ou des mini apps.
• Des catalogues exceptionnellement vastes de contenus par abonnement, où l'offre de chaque créateur est un abonnement distinct.
• Un abonnement avec des options complémentaires qui se renouvellent ensemble comme un seul achat, comme des chaînes premium ou du sport.

Apple permet aussi de postuler lorsqu'un autre programme exige l'API. Le Mini Apps Partner Program, qui reverse à ses membres 85% des ventes intégrées éligibles dans les mini apps hébergées, l'impose.

Les endpoints de remboursement sont arrivés plus tard, et ils exigent une signature

La version 1.1, datée du 24 mars 2025, a ajouté Request Transaction Refund et Revoke Subscription. La page du programme d'Apple indique que les apps proposant des contenus par abonnement peuvent aussi être éligibles aux API Cancel, Revoke et Refund pour gérer les résiliations, valider le contenu après l'achat et administrer leurs catalogues. Chaque page d'endpoint ajoute la même condition : votre Account Holder doit signer l'Advanced Commerce API Addendum, et si la dernière version n'est pas acceptée, l'appel renvoie une erreur. C'est l'Addendum, et non la documentation, qui énumère les cas d'usage prévus pour chaque endpoint.

Les trois endpoints, côte à côte

Cancel a Subscription arrête le prochain prélèvement

Cancel désactive le renouvellement automatique. Apple précise que le client garde l'accès jusqu'à la fin de la période en cours. Rien n'est remboursé. C'est le bon choix quand un client veut partir et a déjà utilisé le temps qu'il a payé.

Revoke Subscription met fin à tout, tout de suite

Revoke passe le renouvellement automatique à false et révoque l'abonnement avec un remboursement total ou au prorata. Son corps de requête accepte refundReason, refundRiskingPreference, refundType et requestInfo. Apple envoie ensuite une notification REFUND à votre endpoint App Store Server Notifications V2. La consigne d'Apple est précise : coupez le service à compter de la revocationDate de cette notification, et ne le coupez pas avant son arrivée.

Request Transaction Refund fonctionne élément par élément

C'est l'outil de précision. Vous envoyez une liste d'éléments, et chacun indique un SKU, un refundReason, un refundType et un indicateur revoke. Avec CUSTOM, vous envoyez aussi refundAmount en millièmes de la devise, donc 4990 signifie 4,99. Si vous envoyez un montant avec FULL ou PRORATED, Apple le rejette avec l'erreur 4000155. La réponse contient une transaction signée et, pour les abonnements, les informations de renouvellement signées.

Apple accepte ces valeurs de refundReason : UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER et MODIFY_ITEMS_REFUND. Une septième, SIMULATE_REFUND_DECLINE, sert uniquement aux tests en sandbox et sur TestFlight, et elle existe parce que l'App Store peut dire non.

Apple peut encore refuser votre propre demande de remboursement

Le nom de l'endpoint est honnête. C'est une demande. Deux champs montrent où se situe vraiment la décision.

refundRiskingPreference ouvre la porte à un contrôle de consommation

Apple décrit refundRiskingPreference comme le fait de savoir si l'App Store vous demande des données de consommation pour éclairer sa décision de remboursement. La valeur par défaut est true. Dans ce cas, vous recevez un CONSUMPTION_REQUEST pour votre propre demande de remboursement et vous répondez via Send Consumption Information. Apple demande aux développeurs de répondre dans les 12 heures suivant la réception d'un CONSUMPTION_REQUEST. Passez-le à false et cette notification n'arrive pas.

Les erreurs qui vous disent non

PendingRefundError est celle qu'il faut anticiper. Une cause probable est un client qui a déjà fait la demande à Apple via Report a Problem avant que votre équipe de support n'agisse. Les règles d'éligibilité d'Apple imposent de toute façon à ces apps de proposer un accès au remboursement dans l'app, soit un lien Report a Problem, soit l'API beginRefundRequest, si bien que les deux portes restent ouvertes en même temps.

Ce qu'un remboursement via l'Advanced Commerce API vous coûte en argent

Rembourser de votre propre initiative semble moins cher que de contester un litige. Cela reste de l'argent qui sort, et l'API permet de reproduire facilement certaines erreurs à grande échelle.

Les taxes dans le montant personnalisé

Apple indique qu'un refundAmount demandé doit inclure les taxes dans toutes les régions sauf le Canada et les États-Unis. Une équipe qui calcule un remboursement CUSTOM à partir du prix hors taxes de son SKU remboursera trop peu les clients de toutes les autres vitrines, puis paiera du temps de support pour corriger chaque cas.

Les coûts qui ne reviennent pas

• Reversements : dans un catalogue de créateurs ou chez un hébergeur de mini apps, la part du créateur est souvent versée à la vente. Un remboursement au client ne la récupère pas.
• Licences de contenu : les redevances par titre dues à un ayant droit pour un livre audio ou un cours peuvent être déclenchées par l'accès, selon votre contrat, et un remboursement ne les annule pas.
• Calcul : le streaming, le transcodage et tout travail serveur effectué pour l'achat figurent déjà sur votre facture.
• Appels d'API : les services tiers facturés à la requête, de la synthèse vocale à l'inférence de modèles, restent facturés après le remboursement.

Un remboursement total alors que vous visiez un seul élément

Revoke Subscription rembourse et met fin à tout l'abonnement, options comprises. Si le client ne conteste qu'une option, Request Transaction Refund vous permet de rembourser ce seul SKU, avec revoke activé uniquement pour cet élément. Appeler Revoke Subscription pour une réclamation portant sur un seul élément rend aussi le revenu du forfait de base.

Une checklist avant d'activer ces appels

• Vérifiez que votre Account Holder a accepté l'Advanced Commerce API Addendum en vigueur, et créez une alerte sur l'erreur renvoyée quand il expire.
• Générez un nouveau requestReferenceId UUID pour chaque requête, et ne réutilisez le même que pour relancer un appel qui a expiré.
• Mettez les appels de remboursement en file d'attente. La limite est de 5 par seconde et par app, et une réponse 429 contient un en-tête Retry-After en millisecondes UNIX.
• Testez les refus en sandbox avec SIMULATE_REFUND_DECLINE, et rappelez-vous que les limites du sandbox représentent 10 pour cent de celles de la production.
• Décidez de refundRiskingPreference au cas par cas, et gardez un service de réponse sur la consommation prêt pour la fenêtre de 12 heures quand la valeur reste true.
• Ne coupez l'accès qu'à l'arrivée de la notification REFUND, à compter de sa revocationDate.
• Journalisez le motif, le montant et le SKU de chaque demande, pour que votre propre taux de remboursement soit visible avant qu'Apple ne voie le sien.