Lees de redencode van de terugbetaling die je server al ontvangt, en hij vertelt je of je je app moet repareren of de klant moet aanvechten

Wanneer Apple of Google een van je klanten terugbetaalt, is het geld meestal weg voordat je een stem hebt. Wat daarna op je server landt ziet eruit als een bon, en de meeste teams behandelen het zo. Het is meer dan dat. Elke terugbetaling draagt een redencode, en het is het enige deel van een terugbetaling dat je nog mag lezen nadat de beslissing is genomen. Google Play vertelt je dat de terugbetaling een chargeback was, of een remorse-verzoek, of een aankoop die je eigen app nooit bevestigde. Apple vertelt je of de terugbetaling iets binnen je app de schuld gaf. Lees die code en een terugbetaling houdt op een regel in een rapport te zijn en wordt een instructie: repareer dit, vecht dit aan, of laat deze gaan. Dit is wat elke code betekent, hoe je ze triageert en wat elke kost.

Wat een redencode van een terugbetaling eigenlijk is

Een redencode is het eigen label van de store voor waarom een aankoop is teruggedraaid. Je stelt hem niet in en je kunt er niet mee in discussie. Hij komt achteraf aan een terugbetaling gehecht, en de twee stores tonen hem in verschillende vormen en met een heel verschillende resolutie.

Google Play stempelt een reden en een bron op elke void

De Voided Purchases API van Google Play geeft één record per teruggedraaide aankoop terug, en elk record draagt twee gehele getallen die ertoe doen. De voidedReason zegt waarom de aankoop is teruggedraaid. De voidedSource zegt wie het in gang zette. Samen maken ze van een kale terugbetaling een zin: deze bestelling is teruggedraaid vanwege een chargeback, geïnitieerd door Google, of teruggedraaid als remorse, geïnitieerd door de gebruiker. Je leest ze door de API te pollen of door je te abonneren op de realtime ontwikkelaarsmelding die afgaat wanneer een void landt. Hoe dan ook, de twee getallen zijn de payload die het bewaren waard is.

Apple geeft je een smaller signaal, maar een scherp

Apple overhandigt je geen reden met negen richtingen. Op een terugbetaalde transactie zet Apple revocationReason op een van twee waarden. Een 1 betekent dat de App Store de transactie terugbetaalde vanwege een werkelijk of vermeend probleem binnen je app. Een 0 betekent dat hij terugbetaalde om een andere reden, bijvoorbeeld een onbedoelde aankoop. Het veld verschijnt alleen op transacties die zijn terugbetaald of ingetrokken, naast een revocationDate, binnen de signed transaction info van de REFUND App Store Server Notification. Twee waarden is niet veel, maar degene die ertoe doet, een 1, is Apple dat je vertelt dat de terugbetaling over je product ging, niet over de twijfel van de klant.

De negen redenen die Google Play je geeft

De voidedReason van Google is de rijkste van de twee, en elke waarde is het waard om op het eerste gezicht te kennen omdat elke ergens anders naar wijst. Hier is de volledige set, rechtstreeks uit de VoidedPurchase-resource, met wat elke code je eigenlijk opdraagt te doen.

voidedSource vertelt je wie de trekker overhaalde

Naast de reden zit voidedSource, en het beantwoordt een andere vraag: wie draaide dit terug. Een 0 betekent dat de gebruiker het deed, via zelfbediening of een bank. Een 1 betekent dat de ontwikkelaar het deed, dat ben jij of je eigen tooling die een terugbetaling uitgeeft. Een 2 betekent dat Google het deed, naar eigen oordeel, inclusief de automatische terugbetaling voor een niet-bevestigde aankoop. Wanneer je een piek in voids ziet, is de bron de eerste snede. Een muur van source 2 is Google dat op je account handelt, en dat is meestal een signaal dat terugwijst naar je integratie in plaats van naar je klanten.

Sorteer elke terugbetaling in repareren, aanvechten of accepteren

De reden dat een code nuttig is, is dat hij je vertelt welke van drie reacties een terugbetaling verdient. De meeste teams behandelen alle terugbetalingen hetzelfde en verspillen moeite aan degene die ze nooit kunnen winnen. De codes splitsen netjes.

Repareren: de terugbetalingen die je product veroorzaakte

Sommige codes zijn bugrapporten in de kleren van een terugbetaling. Defect (3) en niet ontvangen (2) bij Google, en een revocationReason van 1 bij Apple, zeggen allemaal hetzelfde: de klant betaalde en je app leverde niet. Niet-bevestigde aankoop (8) is de scherpste hiervan omdat de fout volledig in je facturatiecode zit. Dit zijn de goedkoopste terugbetalingen om te elimineren, omdat je ze elimineert door iets te repareren dat van jou is, niet door iemand te overtuigen. Een stijgend aantal in deze stapel is een productdefect met een bedrag in dollars eraan vast.

Aanvechten: de terugbetalingen die iemand bewerkt

Fraude (5), friendly fraud (6) en chargeback (7) zijn de geschillen. Pure fraude (5) is niet je klant en geen omzet die je ooit zou houden. Friendly fraud (6), waarbij de koper precies kreeg waarvoor hij betaalde en het toen betwistte, is het ene geschil dat je bewijs nog kan bewegen, en chargeback (7) is waar dat bewijs wordt ingediend. Wanneer een van deze landt trek je de toegang in als je dat nog niet deed, en waar een beoordelingsvenster open staat beantwoord je het met wat je over het account weet.

Accepteren: de terugbetalingen die nooit aan jou waren om tegen te houden

Remorse (1) en onbedoelde aankoop (4) zijn de eigen gedachtenwisseling van de klant. Apple's revocationReason van 0 hoort hier ook. Geen functie faalde en geen fraude vond plaats. Je kunt de emmer met onbedoelde aankopen verzachten met een duidelijkere aankoopbevestiging, maar je kunt een remorse-terugbetaling niet wegredeneren, en tijd besteed aan proberen is tijd weggenomen van de repareerstapel waar het geld werkelijk zit.

De valkuil van 30 dagen waardoor redencodes makkelijk verloren gaan

Er is een harde limiet aan Google's kant die dit van een rapportagefunctie in een deadline verandert. Als je de codes niet continu vastlegt, verlies je ze.

De Voided Purchases API kijkt maar 30 dagen terug

Google is expliciet dat de API alleen teruggedraaide aankopen van de afgelopen 30 dagen kan tonen. Oudere voids worden niet teruggegeven, wat voor startTime je ook meegeeft, en de startTime-waarde zelf kan niet eerder dan 30 dagen geleden worden gezet. Erger voor een naïeve integratie: het venster van 30 dagen wordt gemeten aan de hand van wanneer Google's systemen een aankoop als teruggedraaid zien, niet aan de hand van wanneer de aankoop is gedaan of zelfs aan de hand van de voidedTimeMillis in het record. Dus een redencode die je niet binnen dat venster ophaalt is weg, en een maandelijkse exporttaak met welk gat dan ook laat stilletjes voids vallen die het te langzaam was om te vangen.

Wat de redencodes waard zijn in geld

Twee codes dragen een specifieke prijs, en ze lezen is hoe je een getal plakt op problemen die anders verborgen blijven binnen een geaggregeerd terugbetalingspercentage.

Eén code is een rekening die je jezelf schreef

voidedReason 8, unacknowledged purchase, is het schoonste voorbeeld van een terugbetaling die je zelf veroorzaakte. Google Play vereist dat je app een aankoop bevestigt binnen drie dagen na het verlenen van het recht, en als je dat niet doet betaalt Google de bestelling automatisch terug en trekt het item in. Elke void gestempeld met 8 is een echte verkoop, van een klant die het product wilde, teruggegeven omdat een aanroep om de aankoop te bevestigen nooit afging. Het verloren bedrag is de volledige verkoopprijs plus de rekenkracht, API-aanroepen en opslag die je al uitgaf om het te leveren. Dit is geen terugbetaling die je onderhandelt. Het is een bug die je dicht, en de code is hoe je hem vindt.

De chargeback-code draagt nu een kostenpost

voidedReason 7, chargeback, veranderde van kosten op 3 augustus 2026. Voor Google Play-bestellingen geplaatst op of na die datum kost een verloren chargeback de ontwikkelaar de aankoopprijs minus de servicekosten van Play, plus de chargeback-kosten van de bank, terwijl Google alleen zijn eigen servicekosten dekt. Omdat chargeback-kosten vast zijn en productprijzen niet, kan bij een goedkope in-app-aankoop de kostenpost alleen al meer bedragen dan wat de klant betaalde. Je code 7-voids tellen is nu een kostenpost tellen, niet slechts een verloren verkoop, en precies daarom verdient de chargeback-emmer een eigen rij in elk terugbetalingsrapport dat je bouwt.

Hoe Apple en Google zich verhouden

De twee stores beantwoorden dezelfde vraag op verschillende resoluties, dus een store-overschrijdend terugbetalingsrapport moet ze normaliseren in plaats van te verwachten dat ze overeenkomen.

De stores zullen je nooit dezelfde code geven voor dezelfde terugbetaling, en dat is prima. Wat telt is dat beide je een machine-leesbare reden overhandigen, en beide een team belonen dat hem leest. Apple's enkele bit vertelt je wanneer een terugbetaling de schuld van je product is. Google's negen redenen en zijn bronvlag vertellen je welke productbug, welk geschil en welk zelf toegebracht facturatiegat je voor je hebt. Geen enkele code houdt een terugbetaling tegen. Beide vertellen je wat te doen zodat de volgende niet gebeurt.

RefundHalt legt de redencode bij elke terugbetaling vast op het moment dat hij aankomt, op beide stores, en houdt hem ruim binnen Google's venster van 30 dagen zodat er niets wegglipt. Het sorteert elke void in repareren, aanvechten of accepteren, zodat een piek in code 3 defect je bereikt als een productalarm en een piek in code 8 niet-bevestigd je bereikt als een integratiebug, niet als een vage daling in omzet. Het beantwoordt Apple's CONSUMPTION_REQUEST binnen 12 uur en Google Play's chargeback-beoordeling binnen 24, en het trekt de toegang in op het moment dat een terugbetaling of chargeback landt. Je kunt de code die een store op een terugbetaling stempelt niet veranderen. Je kunt er wel voor zorgen dat je elke code leest, en handelt op degene die werkelijk aan jou zijn om te repareren.