Apple kan een reeds verleende terugbetaling terugdraaien, en een teruggedraaide terugbetaling die je server negeert sluit een klant buiten die heeft betaald

Een terugbetaling is niet altijd het laatste woord. De App Store kan een reeds verleende terugbetaling terugdraaien nadat de klant die aanvecht, en wanneer die teruggedraaide terugbetaling op je server aankomt draagt ze een instructie: geef de toegang terug. De meeste teams richten de gewone REFUND-melding in, sluiten de klant af, en stoppen daar. Ze bouwen de andere helft nooit. Dus wanneer de terugdraaiing binnenkomt, draait er niets, en een klant die opnieuw betaalt zit buitengesloten van wat hij heeft gekocht. Zo werkt de volledige set terugbetalingsmeldingen op de App Store en Google Play, en wat elke melding je kost wanneer je ze negeert.

De App Store stuurt drie terugbetalingsmeldingen, niet een

De meeste terugbetalingsafhandeling is gebouwd voor een gebeurtenis: het geld ging terug, sluit de klant af. De App Store Server Notifications V2-feed draagt eigenlijk drie afzonderlijke terugbetalingsuitkomsten, en ze vragen om drie verschillende dingen. Twee ervan veranderen waartoe een klant toegang heeft. Een ervan maakt de eerste ongedaan. Hier is de volledige set, in Apples eigen woorden.

REFUND, degene die elk team afhandelt

Wanneer de App Store een terugbetaling verwerkt, stuurt het een REFUND-melding naar de URL die je configureert, en Apples definitie is helder: het 'geeft aan dat de App Store een transactie voor een verbruikbare In-App Purchase, een niet-verbruikbare In-App Purchase, een automatisch verlengend abonnement of een niet-verlengend abonnement met succes heeft terugbetaald.' Je slaat de terugbetaalde transactie op, trekt in wat ze heeft gekocht, en Apple vraagt je om de klant met contextuele berichten in de app te vertellen wat er is veranderd. Dit is de melding die iedereen als eerste inricht, en vaak de enige.

REFUND_DECLINED, degene die niets van je vraagt

REFUND_DECLINED betekent precies wat het zegt: 'de App Store heeft een terugbetalingsverzoek afgewezen.' De klant vroeg erom, Apple zei nee, en de transactie blijft staan. Er verandert niets aan de toegang van de klant, dus je rechtenlogica doet hier niets. De waarde van deze melding is administratie. Het sluit de lus rond een terugbetalingsverzoek dat je mogelijk met een CONSUMPTION_REQUEST hebt beantwoord, en het bevestigt dat de klant nog steeds heeft waarvoor hij heeft betaald. Behandel het als een registratie, niet als een actie.

REFUND_REVERSED, degene die teams verrast

Dit is de melding die de meeste terugbetalingspijplijnen nooit afhandelen. Apples definitie is ondubbelzinnig: REFUND_REVERSED 'geeft aan dat de App Store een eerder verleende terugbetaling heeft teruggedraaid vanwege een geschil dat de klant heeft aangespannen. Als je app content of diensten heeft ingetrokken als gevolg van de gerelateerde terugbetaling, moet je die herstellen.' Lees dat twee keer. Apple gaf de klant een terugbetaling, jij trok de toegang in, en toen besloot Apple dat de terugbetaling niet mocht standhouden en trok die terug. De kosten zijn weer actief. De klant heeft betaald, en als je server alleen weet hoe hij moet intrekken, blijft die klant buitengesloten. Een teruggedraaide terugbetaling is de enige terugbetalingsgebeurtenis die toegang teruggeeft, en het is degene waarvoor bijna niemand bouwt.

Wat een teruggedraaide terugbetaling je werkelijk kost

Een gemiste terugdraaiing is geen afrondingsfout. Volg het geld in beide richtingen, want elke helft verkeerd doen heeft een prijs.

Mis de terugdraaiing en je houdt een betalende klant buitengesloten. Apple heeft de kosten hersteld, dus de klant is opnieuw uit de portemonnee, en je app weigert hem het ding dat hij heeft gekocht. De directe kosten zijn supporttijd en een coulance-terugbetaling die je nu misschien zelf uitgeeft, deze keer zonder winkelcommissie die terugkomt om het te verzachten. De tragere kosten zijn de recensie en het verloop, en op Google Play is precies diezelfde buitengesloten frustratie wat uitmondt in een chargeback.

Mis de oorspronkelijke terugbetaling en je blijft een klant bedienen die niets heeft betaald. De spiegelfout is helemaal nooit intrekken. Een terugbetaalde klant die nog steeds afbeeldingen genereert, je APIs aanroept en je opslag vult, maakt echte kosten tegenover een verkoop die is teruggedraaid. De rekenkracht, de externe aanroepen en de opslag zijn geld dat je al hebt uitgegeven, en niets ervan komt terug met de terugbetaling.

• Supportkosten: een mens die een ticket beantwoordt over toegang die je eigen code heeft verwijderd en nooit heeft hersteld.
• Coulance-terugbetalingen: geld opnieuw uitgeven aan een klant die je ten onrechte hebt buitengesloten, zonder winkelcommissie die terugkomt op een handmatig gebaar.
• Verspilde uitgaven: rekenkracht, API-aanroepen en opslag verbruikt door een terugbetaald account dat je nooit hebt afgesloten.
• Chargeback-risico: op Google Play kan een klant die zich dubbel belast voelt een geschil aanspannen, en een verloren geschil komt nu bij jou terecht.

De teruggedraaide terugbetaling en de gewone terugbetaling zijn dezelfde webhook-feed die in tegengestelde richtingen wijst. Handel de ene af en sla de andere over en je betaalt aan beide kanten.

Waarom Apple een terugbetaling terugdraait, en hoe je revocationReason leest

Een terugdraaiing is niet willekeurig. Apple koppelt het aan 'een geschil dat de klant heeft aangespannen', wat de klant is die de terugbetalingsbeslissing achteraf aanvecht. Toen de terugbetaling voor het eerst werd verleend, droeg de transactie een revocationDate en een revocationReason, en die reden is het waard om te lezen voordat iets verderop erop reageert.

• revocationReason 1: de App Store heeft terugbetaald 'vanwege een daadwerkelijk of vermeend probleem in je app.' Dat is een signaal over je product, niet alleen over deze klant.
• revocationReason 0: de App Store heeft terugbetaald 'om andere redenen, bijvoorbeeld een onbedoelde aankoop.' Geen signaal over app-kwaliteit eraan verbonden.

Wanneer er een REFUND_REVERSED binnenkomt voor die transactie, wordt de intrekking ongedaan gemaakt. Je herstellogica moet het oorspronkelijke transaction id opzoeken, bevestigen dat je het hebt ingetrokken, en het recht exact terugzetten zoals het was.

Google Play stuurt geen terugdraaiing, dus je verzoent in plaats daarvan

Het model van Google Play is anders, en het verschil is belangrijk als je beide winkels via een webhook-handler afhandelt. Er is geen Google-equivalent van REFUND_REVERSED. Googles Real-time developer notifications splitsen terugbetalingsgebeurtenissen op in twee berichten, en terugdraaiingen worden afgehandeld via reconciliatie, niet via een push.

De melding voor geannuleerde aankoop

Wanneer een aankoop in Google Play wordt geannuleerd, ontvangt je server een VoidedPurchaseNotification. Het noemt de purchaseToken en orderId, een productType van subscription of one-time, en een refundType dat ofwel een volledige annulering is ofwel een op hoeveelheid gebaseerde gedeeltelijke terugbetaling bij aankopen van meerdere eenheden. Google zegt dat die gegevens genoeg zijn om de juiste aankoop te vinden en het recht aan te passen. Voor meer verwijst het je naar de Voided Purchases API, een pull-model dat geannuleerde orders opsomt binnen een tijdstempelbereik dat je bevraagt.

De chargeback-beoordeling en de klok van 24 uur

Chargebacks komen via een ander bericht, de PendingRefundReviewNotification. Wanneer een klant een afschrijving bij zijn bank aanvecht, stuurt Google Play deze melding en start een klok. Je hebt 24 uur om orders.reviewrefund aan te roepen met een terugbetalingsvoorkeur en eventueel gebruiksbewijs, zodat Google namens jou een onterechte chargeback kan aanvechten. Google registreert je eerste aanroep en negeert de rest. Dit is Googles tegenhanger van Apples CONSUMPTION_REQUEST, het ene venster waarin jouw kant van een geschil meetelt.

Omdat er geen terugdraai-push is, komt een chargeback die Google aanvecht en wint niet binnen als een keurige herstelgebeurtenis. Je verzoent het aan de hand van de Voided Purchases API en je eigen administratie. De les is dezelfde als op de App Store: een geannuleerde order is niet altijd definitief, en je rechtenstatus moet terug kunnen bewegen, niet alleen vooruit.

Hoe je elke terugbetalingsmelding afhandelt zonder iemand buiten te sluiten

Je hebt geen aparte pijplijnen per winkel nodig. Je hebt een handler nodig die een recht in beide richtingen kan verplaatsen en elk bericht behandelt als mogelijk gedupliceerd.

• Bouw herstellen, niet alleen intrekken. Schrijf voor elk pad dat toegang verwijdert bij een REFUND het omgekeerde dat het herstelt bij een REFUND_REVERSED, gekoppeld aan hetzelfde transaction id.
• Maak het idempotent. Beide winkels kunnen dezelfde melding meer dan eens leveren, dus koppel elke intrekking en herstelling aan het transaction- of order id en maak van een herhaling een no-op.
• Lees de reden voordat je handelt. Gebruik revocationReason om een terugbetaling om app-kwaliteit te onderscheiden van een onbedoelde, en stuur de app-kwaliteitsgevallen naar wie verantwoordelijk is voor productkwaliteit.
• Beantwoord de bewijsvensters op tijd. Stuur Apples consumptiegegevens binnen 12 hours na een CONSUMPTION_REQUEST, en roep orders.reviewrefund aan binnen 24 hours na een PendingRefundReviewNotification.
• Bewaar elke gebeurtenis. Bewaar REFUND_DECLINED en de ruwe meldingen, zodat een terugdraaiing die later binnenkomt kan worden gekoppeld aan de terugbetaling die ze ongedaan maakt.

Niets hiervan verandert of een terugbetaling plaatsvindt. Het verandert of de klant aan de andere kant van een teruggedraaide terugbetaling ooit merkt dat je server het verkeerd deed.