Een terugbetaling via de Advanced Commerce API is de enige manier waarop een iOS-ontwikkelaar een terugbetaling kan starten, en Apple beslist nog steeds

Gewone iOS-ontwikkelaars kunnen een klant geen geld terugbetalen. In juni 2026 beantwoordde een App Store Commerce Engineer een vraag op het ontwikkelaarsforum met één zin: op dit moment is het voor een ontwikkelaar niet mogelijk om zelf een terugbetaling uit te voeren. Er is één uitzondering, en die zit in de Advanced Commerce API. Apps die Apple daarvoor goedkeurt, kunnen een terugbetalingsverzoek via de Advanced Commerce API sturen, een abonnement intrekken met geld terug, of een eigen bedrag aanvragen. Apple beslist nog steeds of het geld wordt overgemaakt.

Wat de Advanced Commerce API is en wie hem krijgt

Apple bracht de Advanced Commerce API uit op 23 januari 2025. Hij verwerkt Apple In-App Purchases voor uitzonderlijk grote catalogi van eigen eenmalige aankopen, abonnementen en abonnementen met optionele add-ons. Je maakt niet elk product aan in App Store Connect. Je definieert SKU's op je eigen server en stuurt ze bij de aankoop naar Apple.

Toegang wordt per app verleend. Je vult een aanvraagformulier in, en Apples pagina over geschiktheid noemt drie bedrijfsmodellen die de kern van de app moeten vormen:

• Uitzonderlijk grote catalogi van eenmalige aankopen, zoals luisterboeken, lessen, cursussen of mini-apps.
• Uitzonderlijk grote catalogi van abonnementscontent, waarbij het aanbod van elke maker een eigen abonnement is.
• Een abonnement met optionele add-ons die samen als één aankoop verlengen, zoals premiumkanalen of sport.

Apple laat apps ook aanvragen als een ander programma de API vereist. Het Mini Apps Partner Program, dat leden 85% uitbetaalt van de kwalificerende In-App Purchase-omzet in gehoste mini-apps, vereist hem.

De terugbetalingsendpoints kwamen later, en ze vragen een handtekening

Versie 1.1, gedateerd 24 maart 2025, voegde Request Transaction Refund en Revoke Subscription toe. Volgens Apples programmapagina kunnen apps met abonnementscontent ook in aanmerking komen voor de Cancel-, Revoke- en Refund-API's, om opzeggingen af te handelen, content na aankoop te valideren en hun catalogi te beheren. Elke endpointpagina stelt dezelfde voorwaarde: je Account Holder moet het Advanced Commerce API Addendum ondertekenen, en als de nieuwste versie niet is geaccepteerd, geeft de aanroep een fout. Het Addendum, niet de documentatie, noemt de toepassingen waarvoor elk endpoint bedoeld is.

De drie endpoints naast elkaar

Cancel a Subscription stopt de volgende afschrijving

Cancel zet automatisch verlengen uit. Volgens Apple houdt de klant toegang tot het einde van de lopende periode. Er wordt niets terugbetaald. Dit is de juiste aanroep als een klant wil stoppen en de betaalde tijd al heeft gebruikt.

Revoke Subscription beëindigt alles meteen

Revoke zet automatisch verlengen op false en trekt het abonnement in met een volledige of naar rato berekende terugbetaling. De body bevat refundReason, refundRiskingPreference, refundType en requestInfo. Apple stuurt daarna een REFUND-melding naar je endpoint voor App Store Server Notifications V2. Apples instructie is precies: zet de dienst uit per de revocationDate in die melding, en zet hem niet uit voordat de melding binnenkomt.

Request Transaction Refund werkt per item

Dit is het precieze gereedschap. Je stuurt een lijst met items, en elk item noemt een SKU, een refundReason, een refundType en een revoke-vlag. Met CUSTOM stuur je ook refundAmount in duizendsten van de valuta-eenheid, dus 4990 betekent 4,99. Stuur je een bedrag mee met FULL of PRORATED, dan weigert Apple het met fout 4000155. Het antwoord bevat een ondertekende transactie en, bij abonnementen, ondertekende verlengingsinformatie.

Apple accepteert deze refundReason-waarden: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER en MODIFY_ITEMS_REFUND. Een zevende, SIMULATE_REFUND_DECLINE, is alleen voor testen in sandbox en TestFlight, en bestaat omdat de App Store nee kan zeggen.

Apple kan ook je eigen terugbetalingsverzoek weigeren

De naam van het endpoint is eerlijk. Het is een verzoek. Twee velden laten zien waar de beslissing echt ligt.

refundRiskingPreference nodigt uit tot een verbruikscontrole

Apple beschrijft refundRiskingPreference als de keuze of de App Store je om verbruiksdata vraagt voor de beslissing over de terugbetaling. De standaardwaarde is true. Staat hij op true, dan krijg je een CONSUMPTION_REQUEST voor je eigen terugbetalingsverzoek en antwoord je via Send Consumption Information. Apple vraagt ontwikkelaars binnen 12 uur te reageren na ontvangst van een CONSUMPTION_REQUEST. Zet hem op false en die melding komt niet.

De fouten die nee zeggen

Op PendingRefundError moet je voorbereid zijn. Een waarschijnlijke oorzaak is een klant die Apple al via Report a Problem vroeg voordat je supportteam iets deed. Apples geschiktheidsregels verplichten deze apps sowieso tot een weg naar terugbetaling in de app, een Report a Problem-link of de API beginRefundRequest, dus beide deuren staan tegelijk open.

Wat een terugbetaling via de Advanced Commerce API je aan geld kost

Op eigen initiatief terugbetalen voelt goedkoper dan een geschil uitvechten. Het blijft geld dat de deur uitgaat, en de API maakt sommige fouten makkelijk op grote schaal te herhalen.

Belasting in het eigen bedrag

Volgens Apple moet een gevraagde refundAmount inclusief belasting zijn in alle regio's behalve Canada en de Verenigde Staten. Een team dat een CUSTOM-terugbetaling berekent op basis van de SKU-prijs zonder belasting, betaalt klanten in elke andere storefront te weinig terug en betaalt daarna met supporttijd om elk geval recht te zetten.

Kosten die niet terugkomen

• Uitbetalingen: in een makerscatalogus of bij een host van mini-apps wordt het aandeel van de maker vaak bij de verkoop uitbetaald. Een terugbetaling aan de klant haalt dat niet terug.
• Contentlicenties: vergoedingen per titel aan een rechthebbende voor een luisterboek of cursus kunnen, afhankelijk van je contract, al door toegang ontstaan, en een terugbetaling draait ze niet terug.
• Rekenkracht: streaming, transcoding en al het serverwerk voor de aankoop staan al op je rekening.
• API-aanroepen: diensten van derden die per verzoek factureren, van spraak tot modelinferentie, blijven gefactureerd na de terugbetaling.

Alles terug terwijl je één item bedoelde

Revoke Subscription betaalt terug en beëindigt het hele abonnement, inclusief add-ons. Betwist de klant maar één add-on, dan kun je met Request Transaction Refund alleen die SKU terugbetalen, met revoke alleen voor dat item. Wie Revoke Subscription aanroept bij een klacht over één item, geeft ook de omzet van het basisabonnement terug.

Een bouwchecklist voordat je dit aanzet

• Controleer dat je Account Holder het huidige Advanced Commerce API Addendum heeft geaccepteerd, en stel een alert in op de fout die terugkomt als het verloopt.
• Genereer voor elk verzoek een nieuwe requestReferenceId als UUID, en hergebruik dezelfde alleen om een verlopen aanroep opnieuw te proberen.
• Zet terugbetalingsaanroepen in een wachtrij. De limiet is 5 per seconde per app, en een 429 bevat een Retry-After-header in UNIX-milliseconden.
• Test weigeringen in de sandbox met SIMULATE_REFUND_DECLINE, en onthoud dat de sandboxlimieten 10 procent van productie zijn.
• Bepaal refundRiskingPreference per geval, en houd een responder voor verbruiksdata klaar voor het venster van 12 uur als hij op true blijft.
• Beëindig toegang pas als de REFUND-melding binnenkomt, per de revocationDate daarin.
• Log reden, bedrag en SKU van elk verzoek, zodat je eigen terugbetalingspercentage zichtbaar is voordat Apple het ziet.