Voorzie elke Google Play-aankoop van een versluierd account-id, of er komt een terugboeking binnen die niet meer te herleiden is

Een Google Play-terugboekingsbeoordeling duikt op met een bestelling en een aankoop-token. Ze vertelt je niet wie de klant is. Als je nooit je eigen identificatie op die aankoop hebt gedrukt, matchte je nu een kaal bestelnummer aan je gebruikerstabel onder een klok van 24 uur, en moet je antwoorden met gebruiksbewijs dat je misschien niet kunt vinden. Het versluierde account-id is de oplossing. Het is een korte tekenreeks die je bij het afrekenen aanhangt en die Google Play bij de aankoop bewaart en je later teruggeeft, zodat elke bestelling te herleiden is naar precies de gebruiker die hem deed. Hier is wat het veld is, waarom het überhaupt bepaalt of je een geschil kunt beantwoorden, en wat het overslaan kost nu een verloren terugboeking een rekening is.

Wat het versluierde account-id eigenlijk is

Het versluierde account-id is een optionele tekenreeks die je doorgeeft aan de Google Play-facturatiestroom wanneer een klant iets koopt. Je stelt het in met setObfuscatedAccountId op de BillingFlowParams-builder, en Google bewaart het naast de aankoop. Het is niet de naam van de klant, niet zijn e-mail en niet zijn Google-account. Het is je eigen identificatie voor je eigen gebruiker, geschreven in een vorm die Google kan bewaren zonder te weten wie de persoon is.

Het is een tekenreeks die je bij het afrekenen instelt, geen naam

In Googles woorden specificeert setObfuscatedAccountId een optionele versluierde tekenreeks die uniek is gekoppeld aan het gebruikersaccount van de koper in je app. Het woord versluierd doet echt werk. Google wil niet je ruwe gebruikers-id of iets wat de persoon identificeert. Het wil een stabiel token dat één op één toewijst aan een gebruiker aan jouw kant, en niets meer. Het veld is beperkt tot 64 tekens, wat een hash comfortabel bevat en niet veel meer.

Google leest het eerst voor zijn eigen fraudecontrole

Voordat het ooit nuttig is voor jou, doet het veld een taak voor Google. De facturatiedocumentatie zegt dat Google Play deze waarde kan gebruiken om onregelmatige activiteit te detecteren, zoals veel apparaten die binnen korte tijd op hetzelfde account kopen, en dat Google deze gegevens gebruikt om verdacht gedrag te detecteren en sommige soorten frauduleuze transacties te blokkeren voordat ze zijn voltooid. De eerste opbrengst van het instellen ligt dus stroomopwaarts, in schonere aankopen en minder van die frauduleuze die later omslaan in annuleringen en geschillen. Google noemt het versluierde account-id en de Voided Purchases API niet voor niets samen als zijn twee kernmiddelen tegen misbruik.

Waarom het telt wanneer een terugboekingsbeoordeling binnenkomt

Een terugbetaling die je ziet aankomen is makkelijk. Het lastige geval is de bankterugboeking, want die begint niet met je klant die met jou praat. Ze begint bij de bank, en Google Play stuurt ze naar je door als een beoordeling met een klok eraan.

Het geschil noemt een bestelling, geen persoon

Wanneer een klant een afschrijving betwist bij zijn bank en Google jouw input nodig heeft, stuurt Google Play een PendingRefundReviewNotification. Dat bericht identificeert de bestelling. Het draagt niet je gebruikers-id, want Google had je gebruikers-id nooit. Het had alleen wat je op de aankoop drukte. Als dat niets was, doorzoek je nu achterstevoren een kaal bestelnummer en aankoop-token tegen je eigen records, hopend dat je het token bij de aankoop hebt gelogd en hopend dat de match ondubbelzinnig is. Als je een versluierd account-id instelde, draagt de aankoop je eigen hash, zoek je de gebruiker op in één query en ga je door naar het opbouwen van bewijs in plaats van naar identiteit jagen.

Wat orders.reviewrefund eigenlijk van je vraagt

Het geschil beantwoorden betekent de methode orders.reviewrefund binnen 24 uur aanroepen. Google registreert je eerste aanroep en negeert de rest, dus het eerste antwoord is het enige antwoord. Dit zijn de velden die het wil, en elk van de bewijsvelden gaat ervan uit dat je al weet bij welke gebruiker de bestelling hoort.

Wat het overslaan eigenlijk kost

Het grootste deel van de geschiedenis van Google Play was een terugboeking die je niet kon verdedigen een verloren verkoop en een schouderophalen. Dat is veranderd. Voor bestellingen geplaatst op of na 3 augustus 2026 belast een verloren terugboeking de ontwikkelaar de aankoopprijs minus Googles servicekosten, plus de terugboekingskosten van de bank. Het geschil dat je niet kunt beantwoorden is nu een regel op de rekening.

Loop één bestelling door. Een klant betwist een aankoop van $9.99 bij zijn bank. Google Play stuurt de beoordeling, en je hebt 24 uur. Als je de aankoop labelde, vind je de gebruiker, zie je dat hij het meeste van wat hij kocht verbruikte, en beantwoord je reviewrefund met een DECLINE-voorkeur en het verbruiksbewijs, wat Google een echte zaak geeft om een onrechtmatig geschil aan te vechten. Als je het niet labelde, kun je de bestelling of niet op tijd identificeren of je antwoordt met niets, het geschil wordt beslist zonder jouw kant, en op een bestelling na 3 augustus betaal je de $9.99 minus Googles kosten terug, plus een vaste bankterugboekingskosten die vaak rond de $20 landt. Op een kleine verkoop kan die vaste kosten alleen al groter zijn dan wat je netto verdiende.

• De verloren opbrengst: je nettoaandeel van de verkoop, teruggedraaid.
• De terugboekingskosten van de bank: een vaste kosten die het kaartnetwerk vaststelt, bovenop berekend bij bestellingen geplaatst na 3 augustus 2026, die een gewone terugbetaling nooit draagt.
• De verspilde uitgaven: de rekenkracht, de API-aanroepen van derden en de opslag die het account al gebruikte, weg of je nu kon antwoorden of niet.
• Het patroon dat je niet kunt zien: zonder een stabiel account-id kun je ook niet zien dat dezelfde gebruiker keer op keer betwist, zodat serieel misbruik zich leest als losstaande eenmalige verliezen.

Hoe je het instelt zonder dat aankopen geblokkeerd worden

Twee regels dekken bijna elke fout die teams met dit veld maken. Hash het id, en stel het overal in.

Hash je gebruikers-id, stuur nooit PII

Zet geen e-mail, geen telefoonnummer en geen ruw persoonlijk detail in dit veld. Google is duidelijk dat het opslaan van PII zoals e-mailadressen in leesbare tekst ertoe leidt dat aankopen worden geblokkeerd, en het beveelt een eenrichtingshash of versleuteling aan om de waarde te genereren. Het nette patroon is een eenrichtingshash van je interne gebruikers-id, elke keer op dezelfde manier berekend zodat dezelfde gebruiker altijd dezelfde tekenreeks van 64 tekens produceert. Gebruik ook niet het Google-account-id van de persoon of je ontwikkelaars-id. De waarde zou alleen iets voor jouw systeem moeten betekenen.

Stel het in bij elke aankoop, en lees het terug op je server

Hang het id aan elke facturatiestroom, eenmalige producten en abonnementen gelijk, zodat geen aankoop ooit ongelabeld blijft. Na de aankoop lees je het op twee plekken terug. Op de client geeft Purchase.getAccountIdentifiers een object terug waarvan getObfuscatedAccountId je de tekenreeks geeft die je instelde. In je backend draagt het serverzijdige aankooprecord het als het veld obfuscatedExternalAccountId, en de serverkopie is degene om te vertrouwen, want een geschil komt binnen op je server, niet op het toestel.

Gebruik setObfuscatedProfileId wanneer één account veel profielen heeft

Als je app toelaat dat één account meerdere profielen bevat, een streaminghuishouden of een game met meerdere personages, stel dan ook setObfuscatedProfileId in. Het is hetzelfde soort gehashte, 64 tekens tellende, PII-vrije tekenreeks, toegespitst op het profiel dat de aankoop deed. Google merkt op dat het instellen van een profiel-id ook vraagt om het account-id door te geven, dus stuur beide. Het resultaat is dat een geschil niet alleen aan het account toewijst maar aan precies het profiel dat het geld uitgaf.

De iOS-parallel, in één regel

De App Store heeft hetzelfde idee onder een andere naam. Op iOS hang je een appAccountToken, een UUID, aan een aankoop, en het komt terug op de transactie en op de CONSUMPTION_REQUEST die Apple stuurt wanneer een klant om een terugbetaling vraagt. De vorm van het probleem is identiek op beide stores. De geschil- of terugbetalingsstroom verwijst naar een transactie, en je eigen identificatie is wat het terugkoppelt aan een gebruiker wiens gebruik je kunt rapporteren.

Niets hiervan is moeilijk te bouwen. Het is makkelijk over te slaan, want de dag dat je de checkout-code schrijft is niet de dag dat een terugboeking binnenkomt, en de kosten van het overslaan zijn tot dan onzichtbaar. RefundHalt stelt de account-identificatie op beide stores in en volgt ze, houdt de koppeling van aankoop naar gebruiker zodat een geschil altijd oplost naar een echte klant, en beantwoordt Google Plays orders.reviewrefund en Apples CONSUMPTION_REQUEST binnen hun vensters met het verbruiksbewijs dat op het moment van verkoop is vastgelegd. De klok van 24 uur is niet het moment om te ontdekken dat je niet kunt zeggen wie het ding kocht.