BillingMeld: varför servern ska verifiera köp istället för appen

Inuti en mobilapp kan ett köp verka enkelt för användaren. Hantrycker på en knapp, bekräftar betalningen, får tillgång till funktionen eller prenumerationen — och förväntar sig att allt därefter ska fungera automatiskt.

För utvecklaren inleds dock en mycket mer komplex process. Man måste verifiera själva köpet, ta hänsyn till förlängningar, avslut av prenumerationer, återbetalningar, transaktionsrecensioner, enhetsbyten och skillnader mellan Apple och Google-butikerna.

Huvudproblemet uppstår när servern börjar anse att klientappen är den sanna källan.

Om appen rapporterar: "Köp är gjort", öppnar servern åtkomst och fortsätter att förlita sig på det initiala tillståndet. Men köpscykeln slutar inte där.

Prenumerationer kan förlängas, autostängs av, betalningar kan återkallas, och operationen kan dras tillbaka av butiken.

Det är därför BillingMeld verifierar köpet inte av appen, utan av servern.

Klienten rapporterar, men beslutar inte

Inom BillingMelds arkitektur är mobilappen inte den huvudsakliga informationskällan gällande köpet.

Appen kan skicka data om ett slutfört köp, men detta är endast en kontrollgrund. Det slutgiltiga beslutet fattas av serverdelen av BillingMeld, som verifierar informationen via Apple eller Google-infrastrukturen.

Det är en grundläggande skillnad.

Telefonappen kan arbeta med gammalt tillstånd, inte få in en ny förändring i tid eller skicka data som inte stämmer med det aktuella köptillståndet.

Dessutom ska klienten inte ha möjlighet att själv avgöra om en användare har rätt till betalad åtkomst.

BillingMeld verifierar exempelvis:

• om köpet verkligen existerar;

• om det hör till rätt app och produkt;

• om den betalda perioden är aktiv just nu;

• om en förlängning skedde;

• om automatisk förlängning är avstängd;

• om återbetalning skett;

• om operationen har återkallats;

• om den betalda perioden har löpt ut.

Följaktligen blir klientens rapport inte ett bevis på köp, utan en anledning att verifiera dess faktiska status.

En gemensam sanningskälla för servrar

De anslutna tjänsterna behöver inte själva implementera ett fullt integrationssystem för både Apple och Google samtidigt.

De vänder sig till BillingMeld och får ett redan normaliserat köptillstånd.

Exempelvis: tillgången är aktiv, den betalda perioden har löpt ut, en förlängning är bekräftad, autostängning är avstängd eller köpet har återkallats.

Detta gör det möjligt att tydligt dela ansvar.

Apple och Google är källor till själva transaktionens tillstånd. BillingMeld verifierar denna data, konverterar den till en gemensam modell och bevarar det aktuella tillståndet. Slutprodukten fattar beslut om tillgången baserat på BillingMelds status.

För serverbaserade tjänster innebär detta ett enhetligt kontrakt istället för flera oberoende integrationer.

Det krävs inte att varje tjänst själv implementerar regler för App Store, Google Play och konverterar mellan olika format, händelser och statuser.

Varför man inte kan lita helt på klienten

Klientappen körs på användarens enhet.

Den kan stängas, startas om, återställas från backup, uppdateras eller installeras på en annan enhet. Den kan arbeta med gammal information en tid eller helt missa händelser som skett efter det initiala köpet.

Även utan användarens inblandning är detta en dålig källa för den slutgiltiga statusen för en prenumeration.

Till exempel: en användare tecknar en prenumeration och får tillgång. Senare kan köpet återkallas eller butiken kan dra tillbaka transaktionen.

Om servern bara känner till den initiala rapporten från klienten, kan den fortsätta betrakta köpet som giltigt.

I ett annat fall kan användaren ha avaktiverat autostängning. Då bör den redan betalda perioden fortfarande vara aktiv fram till dess slutdatum.

Om systemet bara använder en enkel status som "abonnemang finns / finns inte", riskerar det att stänga av tillgången för tidigt eller förlänga den efter att rätten gått ut.

BillingMeld bygger på en annan logik: klienten bekräftar inte sina rättigheter. Den rapporterar en händelse, medan servern avgör den faktiska köpsituationen.

Köp är mer än en enskild händelse

En av de vanligaste felaktigheterna i betalningsarkitekturen är att betrakta ett köp som en enskild händelse.

I själva verket har det ett livscykel.

Först kommer en transaktion. Därefter bekräftar butiken köpet. En betald period påbörjas för abonnemanget. Senare kan ytterligare förlängningar ske.

Användaren kan ha avaktiverat autostängning, men fortsätta använda prenumerationen till dess att den betalda perioden är slut.

Betalningar kan misslyckas vid nästa förlängning.

En återbetalning kan göras.

I vissa fall kan köpet dras tillbaka.

Det räcker inte att ha bevis på att köpet existerade vid tidpunkten.

Servern måste förstå vad som händer just nu.

Återkallande av köp märks tydligt

Särskilt tydligt är behovet av serverlösningar vid återkallanden och operationer.

Initialköpet kan ha varit fullständigt korrekt; användaren kan ha betalat för produkten och fått tillgång.

Men senare kan tillståndet ha förändrats.

Om BillingMeld får information om förändringen, uppdaterar den sitt eget tillstånd och verifierar vid behov ytterligare via butiken.

Det anslutna tjänsten arbetar sedan med den nya statusen.

Detta förhindrar att appen fortsätter att lita på gamla, felaktiga data om att köpet existerade för flera veckor eller månader sedan.

Om butiken inte längre anser att rätten är giltig, återspeglas detta i BillingMelds tillstånd.

Avslut av prenumeration och slut på åtkomst är inte samma sak

Det finns en viktig skillnad här.

Om en användare har stängt av autostängning för prenumerationen betyder det inte att åtkomsten ska omedelbart avbrytas.

Den aktuella betalperioden kan fortfarande vara aktiv.

BillingMeld ska då spara information om att vidare förlängning är avstängd, samtidigt som den förstår när den redan betalda perioden tar slut.

Först när perioden är över och inget nytt bekräftat förlängningssteg har skett, avbryts åtkomsten.

Detta illustrerar varför ett enkelt boolean-värde som subscription = true inte är tillräckligt för korrekt hantering.

Status för prenumerationen är alltid tidsberoende och knuten till dess livscykelhändelser.

Förlängningar kräver också separat kontroll

En prenumeration slutar inte efter första betalningen.

Servern måste kunna verifiera om ytterligare förlängningar skett och om den kommande betalda perioden är bekräftad av butiken.

BillingMeld följer sådana förändringar och uppdaterar prenumerationens status.

Om förlängningen är bekräftad, fortsätter rätten till tillgång.

Om betalning misslyckas eller butiken inte längre bekräftar nästa period, ska systemet inte bara automatiskt förlänga åtkomsten baserat på antaganden.

För användaren ser det naturligt ut: tillgången är aktiv så länge den betalda perioden gäller.

För utvecklare innebär detta att samma förlängningslogik inte behöver implementeras i varje app.

Hur ett typiskt scenario ser ut

En användare tecknar en prenumeration i en mobilapp.

Klienten mottar köpsinformationen och skickar nödvändig data till BillingMeld. Men detta är ännu inte en definitiv bekräftelse på köpets status.

BillingMeld verifierar transaktionen via den relevanta butiken.

Om App Store eller Google Play bekräftar köpet och dets status motsvarar produktens regler, registrerar BillingMeld en aktiv rättighet.

Efter det ger den anslutna tjänsten användaren tillgång till de betalda funktionerna.

Det aktuella tillståndet lever vidare oberoende av den initiala rapporten från klienten.

Om prenumerationen förlängs, tar BillingMeld hänsyn till den nya betalda perioden.

Om användaren avaktiverar autostängning, fortsätter denna period att vara aktiv fram till sitt slutdatum.

Om en återbetalning eller operation dras tillbaka, ändras tillståndet åter till en tidigare eller ny status.

I denna modell lagrar inte appen någon egen "sanning" om köpets status. Den arbetar med den status som verifierats och sparats av BillingMeld.

Vad händer vid byte av enhet

Serverbaserad modell är särskilt användbar när en användare byter telefon eller installerar om appen.

Rätten till ett köp ska inte behöva existera enbart för att en specifik enhet tidigare sett en lyckad transaktion.

Å andra sidan ska en ominstallation inte radera ett verifierat rättighetsbevis för användaren.

Om tillståndet för köpet finns på servern och är kopplat till en verifierad butikstransaktion, kan den nya enheten erhålla aktuellt tillstånd via servern.

Det är ytterligare en anledning att inte enbart lagra åtkomstlogik i mobilklienten.

Vad detta innebär för utvecklare

För ett team som utvecklar flera mobila appar eller arbetar både med iOS och Android, snabbt blir betalningshanteringen en separat infrastrukturell uppgift.

Det innebär att ta hänsyn till:

• olika dataformat för Apple och Google;

• bekräftelse av initialt köp;

• förlängningar av prenumerationer;

• avslutning av betalda perioder;

• avstängning av autostängning;

• återbetalningar;

• återkallanden av operationer;

• installation av appen igen;

• enhetsbyte;

• återställning av köp;

• ändringar i tillstånd som skett utan klientens deltagande.

BillingMeld hanterar denna logik i ett separat specialiserat lager.

Serverplattformar arbetar med den enligt ett enhetligt kontrakt och behöver inte tolka varje butiks specifika regler själva.

Det här minskar duplicering av kod och, ännu viktigare, minskar risken för att olika appar från samma företag tolkar samma betalningsscenario olika.

Det är inte kvittot som är det viktiga, utan rättigheten

Det som mest fångade mitt intresse i denna arkitektur är övergången från att verifiera enskilda köp till att kontrollera aktuellt tillstånd.

Ett betalningshistoriskt faktum svarar inte längre på den väsentliga frågan för produkten:

Har användaren rätt till den betalade funktionen nu?

Det kan finnas ett framgångsrikt inledande köp men ett slutat betalt period.

En prenumeration kan ha avaktiverad autostängning men ändå vara aktiv till dess att den betalda perioden är slut.

En bekräftad förlängning kan finnas.

En returnering kan ha skett.

Butiken kan ha dragit tillbaka operationen.

Därför är det inte kvittot eller det initiala svaret från klienten som är det viktigaste, utan användarens aktuella rättighet baserad på verifierat tillstånd.

Detta är det tillstånd som BillingMeld förmedlar till övriga tjänster.

BillingMeld som gräns mellan butiker och appar

Det skapar en tydlig arkitektonisk gräns.

På ena sidan finns App Store och Google Play med sina format, händelser, regler och köpcykler.

På andra sidan finns appar och interna tjänster som oftast bara behöver ett enkelt svar: vilka rättigheter har användaren just nu?

Mellan dem finns BillingMeld.

Den tar emot butikarnas data, verifierar den, konverterar till sin egen modell och tillhandahåller ett normaliserat resultat till resten av infrastrukturen.

Detta gör att produkterna inte behöver känna till varje appspecifik detalj för betalningsplattformen.

Varför detta är viktigt för användaren

En riktig betalningsarkitektur bör i princip vara osynlig för användaren.

Om köpet är verifierat och den betalda perioden är aktiv, ska tillgången fungera.

Om användaren har avaktiverat autostängning, ska den redan betalda perioden inte försvinna i förtid.

Om en förlängning sker, ska tillgången fortsätta.

Om butiken bekräftar en retur eller ett återkallande, ska systemet korrekt reflektera förändringen i rättigheten.

Vid enhetsbyte eller ominstallation av appen ska användaren inte behöva bevisa för alla delar av infrastrukturen att köpet är giltigt.

Regeln kan enkelt sammanfattas:

klienten rapporterar köpet, butiken är den externa källan till dess tillstånd, BillingMeld verifierar och normaliserar tillståndet, och resten av tjänsterna fattar beslut på grundval av den bekräftade informationen från BillingMeld.

Det är därför BillingMeld inte är bara ytterligare en betalmodul.

Det är ett serverbaserat tillitsskikt mellan mobilappen, Apple- och Google-butikerna och produkterna, som behöver en exakt förståelse av vilka betalrättigheter användaren har just nu.

Mer information om projektet finns på: billingmeld.de.