Elke restitutie bij een abonnementsupgrade is de beslissing van de store, niet die van u, en ze gaat rechtstreeks van uw opbrengsten af

Een klant tikt op upgraden, stapt over van uw niveau van vijf dollar naar uw niveau van tien dollar, en u boekt een grotere verkoop. De store doet op datzelfde moment iets anders, en u ziet het nooit. Hij geeft die klant een restitutie bij de abonnementsupgrade voor de dagen die hij op het oude plan al had betaald, en dat geld komt uit uw opbrengsten. Niemand heeft het u gevraagd. In de App Store vindt u het bedrag niet eens terug in de gebeurtenissen die uw server ontvangt.

Dit is niet de restitutie die u kunt aanvechten. Het is geen CONSUMPTION_REQUEST van Apple en geen terugboekingsbeoordeling van Google Play. Het is een verrekening naar rato, ingebouwd in de manier waarop beide stores mensen van plan laten wisselen, en ze loopt vanzelf, elke keer dat een abonnee een niveau omhoog gaat. Hier leest u wat een upgraderestitutie in elke store werkelijk is, waarom Apple het bedrag buiten uw server houdt, en wat de verkeerde instelling in Google Play u kost.

Wat een restitutie bij een abonnementsupgrade werkelijk is

Een upgraderestitutie is de store die afrekent voor tijd die de klant heeft betaald maar niet zal gebruiken. Ze heeft niets te maken met een klacht, een geschil of uw restitutiebeleid. Ze wordt alleen door de mechaniek van de planwissel geactiveerd.

Het is een verrekening naar rato, geen klacht van een klant

Wanneer een abonnee midden in een factureringsperiode naar een hoger niveau overstapt, heeft hij tot het einde van die periode al tegen de oude prijs betaald. De store vergoedt hem voor het ongebruikte deel. Apple geeft een naar rato berekende restitutie van het oorspronkelijke abonnement. Google Play crediteert de ongebruikte waarde op het nieuwe plan. Geen van beide verloopt via een stroom waarop u kunt reageren, en geen van beide wacht op uw goedkeuring.

Alleen een upgrade activeert ze

De richting van de wissel bepaalt het geld. In de App Store is een upgrade een overstap naar een product met een hogere rang binnen dezelfde abonnementsgroep, en alleen die overstap is meteen en met restitutie. Een downgrade is een overstap naar een lagere rang, en die wordt van kracht bij de volgende verlenging, zonder restitutie. Een crossgrade is een overstap tussen producten met dezelfde rang, en de timing hangt af van de betrokken looptijden. Rangschik de producten verkeerd in App Store Connect en een wissel die u voor een upgrade houdt, gedraagt zich als iets anders.

Waarom de App Store de upgraderestitutie voor uw server verbergt

Hier is het deel dat de omzetrapportage breekt. Apple geeft de upgraderestitutie, maar vertelt uw server nooit hoeveel het heeft gerestitueerd.

isUpgraded is het enige signaal, en de prijs klopt niet

De nieuwe transactie komt binnen met isUpgraded op true, wat u vertelt dat er een planwissel heeft plaatsgevonden. Het prijsveld op die transactie toont nog steeds de volle weergaveprijs van het nieuwe niveau, niet het bedrag dat Apple van het oude heeft teruggehaald. Geen enkele App Store Server Notification bevat het restitutiebedrag. In Apples eigen woorden op de ontwikkelaarsforums is het naar rato berekende restitutiebedrag niet beschikbaar via de App Store Server API, Notifications of StoreKit, en zijn de rapporten van App Store Connect uw bron voor alle doeleinden van financiële boekhouding.

Het financiële rapport is de enige eerlijke registratie

De financiële en verkooprapporten van App Store Connect verantwoorden de naar rato berekende upgraderestitutie, want die rapporten bepalen wat Apple u werkelijk uitbetaalt. Daarmee zijn ze de bron van waarheid voor elke abonnee die ooit is opgeklommen. Bouw uw boekhouding op de rapporten, en behandel de servergebeurtenissen als signalen van toegangsrechten, niet als omzet.

Wat het u kost, in geld

De upgraderestitutie is geen afrondingsfout. Het zijn echte opbrengsten, en bij Google Play kiest u bovendien hoeveel van de ongebruikte tijd u weggeeft.

De restitutie zijn opbrengsten die u al had geboekt

Neem een abonnee op uw niveau van 9.99 per maand die op dag 20 van een cyclus van 30 dagen upgradet naar 19.99. Ongeveer een derde van de maand is ongebruikt, dus Apple restitueert ongeveer 3.33 van de oorspronkelijke 9.99. U verliest niet de hele verkoop. U geeft het deel terug dat de klant vooraf betaalde en niet zal gebruiken. Wat telt is dat de teruggave automatisch is en op de oude verkoop landt, zodat de opbrengsten die u al had geteld achteraf krimpen. Vermenigvuldig dat met elke abonnee die midden in de cyclus opklimt en het is een regel die u zou moeten kunnen zien, geen gat dat u in de uitbetaling ontdekt.

Bij Google Play is de vervangingsmodus de echte kostenhefboom

Google Play zet bij een upgrade geen geld terug op de kaart. Het verrekent de ongebruikte tijd op een van meerdere manieren, en u kiest welke door een vervangingsmodus mee te geven wanneer u de aankoopstroom start. De keuze bepaalt of u de klant betaalde tijd geeft of hem het verschil in rekening brengt. Google raadt CHARGE_PRORATED_PRICE aan voor upgrades en DEFERRED voor downgrades, maar de standaard van de bibliotheek is WITH_TIME_PRORATION, dus een stroom die u nooit hebt geconfigureerd, crediteert stilletjes tijd.

Hoe u voorkomt dat upgraderestituties uw boeken verrassen

U kunt de verrekening naar rato niet uitschakelen, en dat zou u ook niet willen, want ze maakt een planwissel eerlijk voor de klant. Wat u wel kunt doen, is ze zien, ze inprijzen en ze gescheiden houden van de restituties die u werkelijk kunt betwisten.

Stem Apple-upgrades af op het financiële rapport

Omdat het restitutiebedrag uw server nooit bereikt, zijn de financiële en verkooprapporten van App Store Connect de enige plek waar een naar rato berekende upgraderestitutie opduikt. Stem de abonnee-omzet elke periode af op die rapporten, en bereken de omzet niet uit een lopend totaal van Server Notifications. De isUpgraded-vlag vertelt u dat er een wijziging heeft plaatsgevonden. Het rapport vertelt u wat ze heeft gekost.

Kies de vervangingsmodus in Google Play bewust

Geef voor elke planwissel bewust een vervangingsmodus mee. Gebruik CHARGE_PRORATED_PRICE wanneer u het prijsverschil bij een upgrade nu wilt innen. Laat WITH_TIME_PRORATION alleen staan wanneer u de klant de resterende tijd wilt geven. Gebruik DEFERRED voor downgrades zodat u de huidige omzet behoudt tot de looptijd afloopt. De standaard is een beslissing, en de verkeerde standaard geeft marge weg, upgrade na upgrade.

Houd upgraderestituties gescheiden van restituties die u kunt betwisten

Een upgraderestitutie is per ontwerp automatisch en definitief. Het is geen klant die zijn geld terugvraagt. De restituties waarop u werkelijk invloed hebt, zijn de door de klant gestarte, waarbij Apple een CONSUMPTION_REQUEST stuurt en u 12 uur geeft om te reageren, en waarbij Google Play via orders.reviewrefund een terugboekingsbeoordeling opent met een venster van 24 uur. Label uw gegevens zo dat de twee nooit door elkaar lopen. De ene regel verrekent u. De andere regel beantwoordt u, tegen de klok.

De korte versie

Wanneer een klant een abonnement upgradet, verrekent de store de ongebruikte tijd voor hem automatisch. Apple restitueert het naar rato berekende bedrag van het oude plan meteen en stuurt uw server het cijfer nooit, dus de financiële rapporten van App Store Connect zijn de enige nauwkeurige registratie. Google Play crediteert de tijd of berekent het verschil afhankelijk van de vervangingsmodus die u instelt, en de standaard geeft de klant betaalde tijd die u levert tegen kostprijs. Niets ervan verloopt via een CONSUMPTION_REQUEST of een terugboekingsbeoordeling, dus er is niets te betwisten. Verreken de upgraderestitutie, stel uw Google Play-modus bewust in, en houd ze gescheiden van de restituties die u nog kunt aanvechten.