BillingMeld: hvorfor serveren bør bekræfte købet i stedet for appen

Indkøb i mobilen er normalt simpelt for brugeren. Han klikker på en knap, bekræfter betalingen, får adgang til en funktion eller et abonnement — og forventer, at alt derefter fungerer automatisk.

For udvikleren starter processen bag knappen dog meget mere komplekst. Det er nødvendigt at bekræfte selve købet, håndtere fornyelser, udløb, refunds, operationernes feedback, enhedsskift og forskelle mellem Apple og Google butikkerne.

Det største problem opstår, når serveren begynder at regne med, at klientappen er den eneste sande kilde til sandheden.

Hvis appen siger: "Købet er gennemført," åbner serveren adgang og fortsætter med at basere sig på den én gang opnåede status. Men købsprocessen stopper ikke her.

Abonnementet kan forlænges, automatisk fornyelse kan deaktiveres, betalingen kan refunderes, og operationen kan trække tilbage fra butikken.

Derfor bekræftes købet i BillingMeld ikke af appen, men af serveren.

Klienten rapporterer, men beslutter ikke

I BillingMelds arkitektur er mobilappen ikke den primære informationskilde om et køb.

Klienten kan sende oplysninger om en gennemført operation, men det er kun en basis for verificering. Den endelige beslutning træffes af serverdelen af BillingMeld, som tjekker informationen via Apple eller Google infrastruktur.

Det er en grundlæggende forskel.

Appen på telefonen kan arbejde med gamle data, modtage ændringer for sent, eller sende data, der ikke længere stemmer overens med den aktuelle købsstatus.

Derudover bør klienten ikke selv kunne afgøre, om brugeren har ret til adgang mod betaling.

BillingMeld verificerer, for eksempel:

• om købet overhovedet findes;

• om det tilhører det rigtige app og produkt;

• om den betalte periode er aktiv;

• om der er sket en forlængelse;

• om automatisk fornyelse er deaktiveret;

• om der er blevet foretaget en refundering;

• om operationen er blevet trukket tilbage;

• om den betalte periode stadig er aktiv.

På den måde bliver klientens besked ikke bevis for købet, men en anledning til at tjekke dens aktuelle status.

Ensartet sandhedskilde for servere

De tilknyttede tjenester behøver ikke selv implementere hele integrationssættet med både Apple og Google samtidigt.

De henvender sig til BillingMeld og modtager allerede normaliseret købsstatus.

For eksempel: adgang er aktiv, den betalte periode er udløbet, en forlængelse er bekræftet, automatisk fornyelse er deaktiveret, eller købet er trukket tilbage.

Det gør det tydeligt at fordele ansvaret.

Apple og Google er kilder til operationens tilstand. BillingMeld verificerer disse data, formatterer dem i en fælles model og opdaterer den aktuelle status. Produktet træffer beslutningen om adgang baseret på BillingMelds status.

For serverne i produkter betyder det en ensartet kontrakt i stedet for flere uafhængige integrationer.

Der er ikke behov for at gennemføre separate regler for App Store og Google Play, og derefter forsøge at harmonisere dataformater, hændelser og statuser i én fælles logik.

Hvorfor man ikke kan stole fuldt ud på klienten

Klienten kører på brugerens enhed.

Det kan lukkes, genstartes, gendannes fra backup, opdateres senere eller køres på en anden enhed. Det kan længe arbejde med gamle data eller slet ikke modtage en hændelse, der fandt sted efter den oprindelige købsbegivenhed.

Selv uden brugerindblanding er klienten en dårlig kilde til den endelige status for abonnementet.

Eksempelvis kan en bruger tegne et abonnement og få adgang. Senere kan der være en refundering, eller butikken kan tilbagetrække købet.

Hvis serveren kun kender til det oprindelige besked fra klienten, vil den fortsætte med at regne købet som aktivt.

En anden situation er, at brugeren deaktiverer automatisk fornyelse, men det betalte abonnement stadig skal være aktivt indtil udløbsdatoen.

Hvis systemet kun opererer med simple tilstande som "abonnementet eksisterer / eksisterer ikke," vil det nemt åbne for tidlig lukning af adgang eller for langvarig adgang efter udløb.

BillingMeld er baseret på en anden logik: klienten bekræfter ikke rettighederne selv. Den rapporterer hændelser, og serveren fastlægger den faktiske købsstatus.

Købet er ikke bare én hændelse

En af de største fejl i billing-arkitekturen er at betragte købet som én enkelt hændelse.

Faktisk har det en livscyklus.

Først opstår en operation. Dernæst bekræftes den af butikken. For et abonnement starter den betalte periode. Senere kan der ske en fornyelse.

Brugeren kan deaktivere automatisk fornyelse, men fortsætte med at bruge abonnementet indtil udløb af den betalte periode.

Betalingen kan fejle ved næste fornyelse.

Der kan være en refusion.

I nogle tilfælde kan købet tilbagekaldes.

Derfor er det ikke tilstrækkeligt at kende det faktum, at "købet engang fandtes."

Det er vigtigt for serveren at vide, hvad der sker med købet nu.

Tilbagekaldelse af køb bliver ikke overset

Særligt tydeligt viser behovet for serverarkitektur sig ved refusioner og tilbagekaldelser.

Den oprindelige købsbekræftelse kunne have været helt korrekt. Brugeren har betalt og fået adgang.

Men senere ændres operationens tilstand.

Hvis BillingMeld modtager information om ændringen, opdaterer den sin egen købsstatus og verificerer eventuelt via butikken.

Herefter arbejder det tilknyttede system med den nye status.

På den måde fortsætter appen ikke uendeligt med at stole på, at brugeren for nogle uger eller måneder siden har rapporteret et vellykket køb.

Hvis butikken ikke længere betragter den relevante ret som aktiv, afspejles det i BillingMelds status.

Aflysning af abonnement og udløb af adgang — er ikke det samme

Der er en vigtig forskel.

Hvis brugeren deaktiverer automatisk fornyelse, betyder det ikke nødvendigvis, at adgangen skal lukke med det samme.

Det nuværende betalte perioder kan fortsætte.

I så fald skal BillingMeld gemme information om, at yderligere fornyelse er deaktiveret, men samtidig kende udløbsdatoen for den allerede betalte periode.

Og først efter denne periode er udløbet, kan adgangen betragtes som inaktiv, hvis der ikke er et nyt bekræftet fornyelsespunkt.

Det er et eksempel på, hvorfor en simpel boolean som subscription = true ikke er tilstrækkeligt til et korrekt billing.

Status for abonnementet er altid relateret til tid og hændelser i dets livscyklus.

Fornyelse er også en separat verificering

Et abonnement slutter ikke ved første betaling.

Serveren skal vide, om der er sket en ny fornyelse, og om den næste betalte periode er bekræftet af butikken.

BillingMeld overvåger disse ændringer og opdaterer abonnementsstatus.

Hvis fornyelsen er bekræftet, fortsætter adgangen.

Hvis næste betaling ikke er foretaget, eller hvis butikken ikke længere bekræfter den næste periode, bør systemet ikke blot automatisk forlænge adgangen.

Det ser logisk ud for brugeren: adgangen eksisterer, så længe den betalte periode er aktiv.

For udviklerne betyder det, at den samme fornyelseslogik kan genanvendes i alle apps, uden at skulle implementere den hver gang.

Hvordan et typisk scenarie ser ud

Brugeren køber et abonnement i den mobile app.

Klienten modtager købsinformationen og sender de nødvendige data til BillingMeld. Men denne besked er endnu ikke bevis for, at købet er endeligt bekræftet.

BillingMeld verificerer operationen via den relevante butik.

Hvis App Store eller Google Play bekræfter købet, og dets status opfylder produktets regler, registrerer BillingMeld en aktiv rettighed.

Derefter giver det tilknyttede system adgang til de betalte funktioner.

Derefter lever købsstatus uafhængigt af den oprindelige besked fra klienten.

Hvis abonnementet forlænges, tager BillingMeld højde for den nye betalte periode.

Hvis brugeren deaktiverer automatisk fornyelse, vil den aktuelle periode fortsætte til udløb.

Hvis der sker en refundering eller operationen trækkes tilbage, ændres status igen.

I denne model er appen ikke alene om at opretholde en ”egen sandhed” om købet. Den arbejder med den status, som er bekræftet og gemt i BillingMeld.

Hvad sker der, når en enhed skiftes

Servermodellen er især nyttig, når brugeren skifter telefon eller geninstallerer appen.

Retten til købet bør ikke eksistere blot fordi enheden har set en vellykket transaktion en gang.

Omvendt skal geninstallation af appen ikke ødelægge det bekræftede brugerret.

Hvis købsstatus er opbevaret på serveren og er knyttet til en bekræftet butikstransaktion, kan den nye enhed få adgangsstatus gennem serveren.

Det er endnu en grund til ikke at opbevare adgangskontrol udelukkende i mobilklienten.

Hvad det giver til udviklerne

For et team, der udgiver flere mobilapps eller arbejder både med iOS og Android, bliver billing hurtigt til en særskilt infrastrukturopgave.

Der skal tages højde for:

• forskellige dataformater for Apple og Google;

• bekræftelse af oprindeligt køb;

• abonnementsforlængelser;

• udløb af betalte perioder;

• deaktivering af automatisk fornyelse;

• refusioner;

• tilbagetrækning af operationer;

• geninstallation af appen;

• enhedsskift;

• gendannelse af køb;

• ændringer uden brugerens involvering.

BillingMeld håndterer al denne logik i et separate, specialiseret lag.

Produktsystemerne opererer med det gennem en fælles kontrakt og behøver ikke selv fortolke alle de enkelte butiksspecifikationer.

Det reducerer duplikering af kode og mindsker risikoen for, at forskellige apps i samme virksomhed forstår et betalingsscenarie forskelligt.

Det er ikke kvitteringen, der er det vigtige, men rettigheden

Det, der fascinerede mig mest ved denne arkitektur, er overgangen fra at tjekke et enkelt køb til at kontrollere den aktuelle tilstand.

Historisk set svarer en betalingsbekræftelse i sig selv ikke på det vigtigste spørgsmål for produktet:

Har brugeren ret til den betalte funktion nu?

En operation kan have en vellykket oprindelig købsbekræftelse, men være udløbet.

Et abonnement kan have deaktiveret automatisk fornyelse, men stadig være aktivt inden for den betalte periode.

Der kan være en bekræftet fornyelse.

Der kan være en refundering.

Butikken kan tilbagetrække operationen.

Derfor er det ikke kvitteringen eller brugerens oprindelige svar, der er den vigtigste genstand, men den nuværende rettighed baseret på den bekræftede købsstatus.

Det er denne status, BillingMeld videreformidler til de øvrige tjenester.

BillingMeld som grænseflade mellem butikker og produkter

Dette skaber en tydelig arkitektonisk adskillelse.

På den ene side har vi App Store og Google Play med deres formater, hændelser, regler og købslevetid.

På den anden side er der apps og interne tjenester, der oftest har brug for en enklere vurdering: Hvilke rettigheder har brugeren nu?

Mellem dem står BillingMeld.

Det modtager butikernes data, verificerer dem, tilpasser dem til sin model og giver resten af infrastrukturen et normaliseret resultat.

Det betyder, at produkterne ikke behøver at kende alle butikkernes interne detaljer.

Hvorfor det er vigtigt for brugeren

For brugeren bør den rigtige billingarkitektur i det væsentlige forblive usynlig.

Hvis købet er bekræftet, og den betalte periode er aktiv, bør adgangen fungere.

Hvis brugeren deaktiverer automatiske fornyelser, skal den allerede betalte periode ikke forsvinde for tidligt.

Hvis der sker en ny, vellykket fornyelse, skal adgangen fortsætte.

Hvis butikken bekræfter en tilbagekaldelse eller refusion, skal systemet håndtere rettigheden korrekt.

Ved en enhedsændring eller geninstallation bør den enkelte bruger ikke skulle bevise for hver del af infrastrukturen, at købet virkelig eksisterer.

Det betyder, at en simpel regel kan være:

Klienten rapporterer købet, butikken er den eksterne kilde til dets status, BillingMeld verificerer og normaliserer, og resten tager beslutningen ud fra de bekræftede data.

Derfor er BillingMeld ikke bare en betalingsmodul, men et serverside tillidslag mellem den mobile app, butikkerne Apple og Google, og de produkter, der skal kende brugerens aktuelle betalte rettigheder præcist.

Se mere om projektet: billingmeld.de.