Een Family Sharing-terugbetaling draait één betaling terug maar kan vijf andere mensen achterlaten die je app nog gebruiken, en alleen je server kan hun toegang afsluiten

Eén aankoop in een Family Sharing-groep kan je app aan zes mensen geven. De persoon die betaalde is er een van. De andere vijf openden nooit hun portemonnee, en Apple verwacht toch dat je app voor allemaal werkt. Dat is de afspraak waar je voor kiest op het moment dat je Family Sharing inschakelt voor een in-app-aankoop. Het is ook waarom een Family Sharing-terugbetaling een ander beest is dan een gewone. Wanneer de koper zijn geld terugkrijgt, wordt de verkoop teruggedraaid voor één account, maar de toegang die je aan wel vijf andere mensen verleende schakelt niet vanzelf uit. Je server moet dat doen, en als die geschreven is om alleen de koper te volgen, zal die het niet doen.

Hier is het hele plaatje op één plek. Dit loopt door hoe Apple een gedeelde aankoop markeert, het ene veld dat de koper van het gezin onderscheidt, precies wanneer Apple je een REVOKE stuurt en hoe je die leest, het stille detail dat een terugbetaling scheidt van iemand die simpelweg het gezin verlaat, en wat een gedeelde terugbetaling werkelijk kost zodra je de rekenkracht meetelt die je al uitgaf aan mensen die je nooit betaalden.

Wat Family Sharing uitdeelt, en aan hoeveel mensen

Schakel Family Sharing in voor een product en je verandert wie je betalende klant is. Een gezinsgroep bij Apple kan tot zes mensen bevatten, één organisator en tot vijf leden. Wanneer iemand in de groep een gezinsdeelbaar product koopt, krijgt iedereen in de groep er toegang toe. Ze betalen niet. Ze verschijnen niet in je omzet. Ze duiken gewoon op in je app met een geldig recht, omdat Apple aan elk van hen een transactie uitgeeft die naar dezelfde aankoop verwijst.

Slechts twee producttypes zijn deelbaar, en verbruikbare zijn er geen van

Family Sharing dekt precies twee soorten in-app-aankopen: niet-verbruikbare en automatisch verlengende abonnementen. Verbruikbare producten, de munten-en-credits-producten, worden nooit gedeeld, en daarom activeert een gezinslid nooit een CONSUMPTION_REQUEST en verschijnt het nooit in je verbruiksrapportage. Als je app alleen verbruikbare producten verkoopt, zijn Family Sharing-terugbetalingen niet jouw probleem. Als je een levenslange ontgrendeling of een terugkerend plan verkoopt, wel.

Het veld dat een koper van een begunstigde onderscheidt

Elke transactie die Apple uitgeeft draagt een inAppOwnershipType. Het heeft twee waarden. PURCHASED betekent dat dit account voor het product betaalde en het kan beheren, inclusief het annuleren of een terugbetaling aanvragen. FAMILY_SHARED betekent dat dit account een gezinslid is dat toegang heeft via de aankoop van iemand anders. Beide geven de persoon recht om je product te gebruiken. Slechts een van hen betaalde. Het veld staat op de StoreKit-transactie, de bon en de App Store Server API, dus je kunt het overal lezen waar je al rechten controleert.

Hoe een Family Sharing-terugbetaling je server bereikt

Een terugbetaling op een gedeelde aankoop begint op dezelfde manier als elke Apple-terugbetaling. De koper, de enige die dat kan, vraagt Apple om zijn geld terug. Apple beslist. Als Apple het toekent, wordt de aankoop van de koper teruggedraaid en stuurt Apple je server een REVOKE App Store Server Notification. Zowel V1 als V2 van de notificatie dragen die. De REVOKE is je enige signaal dat het recht erachter, en elke gezinsgedeelde kopie ervan, nu ongeldig is.

Trek niet één transactie in, lees de hele geschiedenis opnieuw

Apple's richtlijn over een REVOKE is bot: behandel het niet als een enkele schakelaar. Wanneer je er een krijgt, loop de volledige transactiegeschiedenis van de klant door en bouw hun rechten vanaf nul opnieuw op, omdat iemand meer dan één transactie kan bezitten die hetzelfde of een ander product verleent. Trek alleen de transactie in die in de notificatie wordt genoemd en je kunt of een terugbetaald gezinslid met actieve toegang laten zitten, of iemand afsluiten die nog een geldig tweede recht heeft. Herstel elke keer het volledige plaatje.

Het ene detail dat een terugbetaling van een gezinsbreuk scheidt

Hier is de valstrik die teams een middag debuggen kost. Een REVOKE kan twee heel verschillende dingen betekenen voor een FAMILY_SHARED-transactie, en de manier waarop je ze onderscheidt is een veld dat soms simpelweg afwezig is. Wanneer de koper een terugbetaling krijgt, komt de FAMILY_SHARED-transactie met een revocationDate. Wanneer een gezinslid gewoon de groep verlaat, komt hetzelfde soort REVOKE helemaal zonder revocationDate binnen. Apple's commerce-engineers hebben dat rechtstreeks op de developerforums gezegd. Hoe dan ook trek je de toegang in, maar alleen die met een datum is een terugbetaling, en alleen de terugbetaling is degene die ook een betaling terugdraaide.

Wat een gedeelde terugbetaling je werkelijk kost

Volg het geld, want dit is waar Family Sharing de rekening stilletjes verandert. Een normale terugbetaling draait één verkoop terug. Apple geeft de prijs terug aan de koper en levert zijn commissie in, dus aan de winkelkant komt het bijna gelijk uit. Wat nooit terugkomt is wat je al uitgaf om het product te leveren. Bij Family Sharing gaf je dat niet één keer uit. Je gaf het uit voor wel zes mensen. De koper en tot vijf gezinsleden lieten elk je rekenkracht draaien, riepen je API's aan, vulden je opslag en trokken alle uitbetalingen die je financiert, allemaal op basis van één betaling.

Nu betaalt de koper terug. Die ene betaling wordt teruggedraaid. De toegang van elk gezinslid zou op hetzelfde moment moeten eindigen, omdat wat het bedienen van hen rechtvaardigde, één betaalde aankoop, weg is. Als je server alleen de PURCHASED-transactie intrekt en de FAMILY_SHARED-transacties actief laat, houden tot vijf mensen je betaalde functies gratis, en blijf je betalen om hen te bedienen, zonder dat er nog iets in het systeem is om tegen te factureren. Dat is geen afrondingsfout. Het is vijf keer de leverkosten van de verkoop die je zojuist terugstortte.

Abonnementen maken het lek terugkerend

Bij een niet-verbruikbaar product is een niet-ingetrokken gezinslid een eenmalig verlies dat loopt tot je het opmerkt. Bij een automatisch verlengend abonnement is het erger, omdat het recht al terugkerend was. Een terugbetaling op de abonnementsbestelling zou het delen voor de hele groep moeten beëindigen, maar een actief gelaten gezinslid houdt het betaalde niveau elke facturatieperiode die je niet afsluit. De oplossing is dezelfde, herstel de rechten vanuit de volledige geschiedenis bij elke REVOKE, maar de kosten van het overslaan ervan stapelen op.

Het goed doen, en het testen voordat een echte terugbetaling dat doet

Er is hier niets exotisch te bouwen. De hele klus is om toegang te koppelen aan het recht, niet aan de koper, en die toegang bij elke REVOKE opnieuw op te bouwen.

• Sla toegang op tegen de transactie en zijn inAppOwnershipType, niet tegen één kopersaccount, zodat een FAMILY_SHARED-transactie op zichzelf toegang verleent en op zichzelf kan worden ingetrokken.
• Lees bij elke REVOKE-notificatie de volledige transactiegeschiedenis van de klant opnieuw en herbereken de rechten, in plaats van de ene genoemde transactie uit te schakelen.
• Behandel een FAMILY_SHARED-transactie met een revocationDate als een terugbetaling en beëindig de toegang van dat lid. Behandel een zonder revocationDate als een gezinsvertrek en beëindig die ook.
• Haast een gloednieuwe gedeelde aankoop niet in gebruik. Apple houdt die ongeveer een uur vast zodat de koper zich kan terugtrekken, dus honoreer de transactie die Apple daadwerkelijk uitgeeft in plaats van toegang te verlenen bij de kooptik.
• Oefen het. Apple's Testing Family Sharing-hulpmiddel laat je een gedeelde transactie simuleren, en een sandbox-terugbetaling vuurt dezelfde REVOKE af die je productieserver zal krijgen.

Doe dat en een Family Sharing-terugbetaling wordt een non-gebeurtenis. De koper krijgt zijn geld, de hele groep verliest de toegang in dezelfde tel, en jij stopt met betalen om mensen te bedienen die je nooit betaalden.