BillingMeld: hvorfor serveren bør bekrefte kjøpet i stedet for appen

Kjøp i en mobilapplikasjon kan ofte virke enkelt for brukeren. Han trykker på en knapp, bekrefter betalingen, får tilgang til funksjon eller abonnement — og forventer at alt videre skal fungere automatisk.

For utvikleren er det imidlertid en langt mer kompleks prosess bak denne knappen. Man må bekrefte selve kjøpet, håndtere fornyelser, abonnementsavslutning, refusjoner, operasjonsvurderinger, enhetsbytte og forskjeller mellom Apple og Google butikker.

Hovedproblemet oppstår når serveren begynner å betrakte klient-appen som den ultimate kilde til sannhet.

Hvis appen rapporterer: "Kjøp fullført", åpner serveren tilgang og fortsetter å styre den basert på den engang mottatte statusen. Men kjøpssyklusen stopper ikke her.

Abonnement kan forlenges, automatisk fornyelse kan være deaktivert, betalingen kan bli refundert, og selve operasjonen kan trekkes tilbake av butikken.

Derfor bekrefter ikke appen kjøpet i BillingMeld, men serveren gjør det.

Brukeren rapporterer, men avgjør ikke

I BillingMelds arkitektur er mobilappen ikke den viktigste kilden til kjøpsinformasjon.

Klienten kan sende data om gjennomført operasjon, men dette er bare et grunnlag for verifisering. Den endelige avgjørelsen tas av serverdelen av BillingMeld, som verifiserer informasjonen gjennom Apples eller Google sin infrastruktur.

Dette er en vesentlig forskjell.

Mobilappen kan operere med gammel status, ikke motta nye endringer i tide, eller sende data som ikke samsvarer med den oppdaterte kjøpsstatusen.

Videre skal klienten ikke ha muligheten til å selv avgjøre om brukeren skal ha betalt tilgang.

BillingMeld bekrefter for eksempel:

• Eksisterer kjøpet virkelig?

• Er det relevant for riktig app og produkt?

• Er den betalte perioden aktiv nå?

• Har det skjedd en forlengelse?

• Er automatisk fornyelse deaktivert?

• Har det vært refusjon?

• Er operasjonen trukket tilbake?

• Har den betalte perioden utløpt?

På denne måten blir brukerens melding ikke bevis på kjøpet, men en anledning til å verifisere den reelle statusen.

Én sannhet for serverne

Tilkoblede tjenester trenger ikke å implementere komplette integrasjoner med både Apple og Google samtidig.

De henvender seg til BillingMeld og mottar en normalisert status for kjøpet.

For eksempel: tilgjengeligheten er aktiv, den betalte perioden er avsluttet, fornyelse er bekreftet, automatiske fornyelser er deaktivert eller kjøpet er trukket tilbake.

Dette gjør det mulig å tydelig fordele ansvar.

Apple og Google er kildene til tilstanden for selve butikkskjøpet. BillingMeld verifiserer disse dataene, normaliserer dem til en felles modell, og oppdaterer den aktuelle statusen. Den endelige beslutningen om tilgang tas deretter basert på BillingMelds status.

For produktservere betyr dette en felles kontrakt i stedet for flere uavhengige integrasjoner.

Det er ikke nødvendig å i hvert enkelt tjenesteforhold implementere regler for App Store, Google Play, og deretter forsøke å harmonisere ulike formater, hendelser og statuser i en felles logikk.

Hvorfor man ikke kan stole fullt og helt på klienten

Klient-appen kjører på en brukers enhet.

Den kan lukkes, startes på nytt, restaureres fra backup, oppdateres senere, eller kjøres på en annen enhet. Den kan jobbe med gammel informasjon over tid, eller ikke motta hendelser som har skjedd etter den første kjøpsmeldingen.

Selv uten brukerinnblanding er dette grunnen til at klienten ikke er en pålitelig kilde til endelig status for abonnementet.

For eksempel: brukeren abonnerer, og får tilgang. Senere kan kjøpet bli refundert eller operasjonen kan trekkes tilbake av butikken.

Hvis serveren kun kjenner til den opprinnelige meldingen fra klienten, vil den fortsatt regne kjøpet som gyldig.

Annen situasjon: brukeren kan deaktivere automatisk fornyelse. I så fall skal den allerede betalte perioden fortsatt være aktiv fram til dens slutt.

Hvis systemet bare bruker en enkel status som «abonnement eksisterer / eksisterer ikke», kan det lett enten stenge tilgangen for tidlig eller beholde den etter utløpsdatoen.

BillingMeld er basert på en annen logikk: klienten bekrefter ikke sine egne rettigheter. Den rapporterer en hendelse, og serveren vurderer den faktiske kjøpsstatusen.

Kjøp er ikke en enkelt hendelse

En av de viktigste feilene i betalingsarkitekturen er å betrakte kjøpet som en enkeltstående hendelse.

Faktisk har det en livssyklus.

Først oppstår en operasjon. Deretter bekreftes den av butikken. For abonnement begynner den betalte perioden. Senere kan det skje fornyelser.

Brukeren kan deaktivere automatisk fornyelse, men fortsatt bruke abonnementet fram til slutten av den betalte perioden.

Betalingen kan mislykkes ved neste fornyelse.

Refusjoner kan finne sted.

I enkelte tilfeller kan kjøpet bli trukket tilbake.

Derfor er det ikke tilstrekkelig å kun kjenne til om «denne kjøpet eksisterte en gang».

Serveren må alltid vite hva som skjer med kjøpet nå.

At tilbakekalling ikke går ubemerket hen

Spesielt tydelig er behovet for en serverbasert arkitektur ved refusjoner og tilbakekallinger.

Den innledende kjøpet kan ha vært helt korrekt, brukeren kan ha betalt og fått tilgang. Men senere kan statusen endres.

Hvis BillingMeld mottar informasjon om endringen, oppdaterer den sin egen kjøpsstatus, og verifiserer eventuelt ytterligere data via butikken.

Deretter opererer tilkoblede tjenester med den oppdaterte statusen.

På denne måten slutter applikasjonen å tillate seg å stole fullstendig på at brukeren rapporterte et vellykket kjøp for flere uker eller måneder siden.

Hvis butikken nå ikke lenger anser rettigheten som gyldig, vil BillingMeld reflektere dette i sin tilstand.

Avslutning av abonnement og tilgang er ikke det samme

Her er det et viktig skille.

Hvis brukeren deaktiverer automatisk fornyelse, betyr ikke det nødvendigvis at tilgangen skal slutte umiddelbart.

Den betalte perioden kan fortsatt være aktiv.

I så fall skal BillingMeld lagre informasjon om at fornyelsen er deaktivert, samtidig som den må kjenne sluttdatoen for den allerede betalte perioden.

Tilgangen anses først som utløpt etter den periodens slutt, dersom ikke en ny bekreftelse har skjedd.

Dette er et eksempel på hvorfor det ikke er nok å bruke en enkel boolean som subscription = true for riktig billettstyring.

Abonnementsstatus er alltid tid- og hendelsessensitiv.

Fornyelse er også en verifiseringsprosess

Abonnementet avsluttes ikke ved første betaling.

Serveren må vite om neste fornyelse har skjedd, og om den nye betalte perioden er bekreftet av butikken.

BillingMeld følger slike endringer og oppdaterer statusen for abonnementet.

Hvis fornyelse er bekreftet, fortsetter retten til adgang.

Hvis neste betaling mislykkes, eller butikken ikke bekrefter den nye perioden, skal systemet ikke bare fortsette å forlenge tilgangen basert på antagelser.

Dette gir brukeren en følelse av at tilgangen varer så lenge den betalte abonnementet er gyldig.

For utviklere betyr det at den samme logikken for fornyelse ikke trenger å implementeres i hver enkelt app.

Hvordan et vanlig scenario ser ut

En bruker abonnerer via en mobilapp.

Klienten mottar informasjon om kjøpet og sender nødvendige data til BillingMeld. Men denne meldingen er ikke i seg selv grunnlaget for å betraktes som et endelig bekreftet kjøp.

BillingMeld verifiserer operasjonen via den relevante butikk.

Hvis App Store eller Google Play bekrefter kjøpet og dets tilstand samsvarer med produktreglene, registrerer BillingMeld en aktiv rettighet.

Deretter leverer den tilkoblede tjenesten brukerrettighetene.

Men tilstanden fortsetter å eksistere uavhengig av den opprinnelige klientsmeldingen.

Dersom abonnementet forlenges, registreres den nye betalte perioden.

Hvis brukeren deaktiverer automatisk fornyelse, varer den nåværende perioden til den utløper.

Hvis operasjonen refunderes eller trekkes tilbake, oppdateres tilstanden igjen.

I dette oppsettet har appen ikke en egen «sannhet» om kjøpet. Den opererer med tilstanden som bekreftes og lagres av BillingMeld.

Hva skjer ved en enhetsbytte

Servermodellen er spesielt nyttig når brukeren bytter telefon eller reinstallere appen.

Retten til kjøpet skal ikke bare eksistere fordi en kopi av appen har sett en vellykket transaksjon en gang.

Og motsatt: en reinstallasjon av appen skal ikke slette brukerens bekreftede rettigheter.

Hvis kjøpsstatusen er lagret på serveren og knyttet til en bekreftet butikkoperasjon, kan det nye enhetskasset få den oppdaterte statusen via serveren.

Dette er en annen grunn til å unngå å lagre tilgangslogikk eksklusivt i mobilklienten.

Hva dette betyr for utviklere

For team som utgir flere mobilapplikasjoner eller arbeider med både iOS og Android, kan billing raskt bli en egen infrastrukturutfordring.

Det må tas hensyn til:

• varierende formater for data fra Apple og Google;

• bekreftelse av det første kjøpet;

• abonnementsfornyelser;

• utløp av betalt periode;

• deaktivering av automatisk fornyelse;

• refusjoner;

• tilbakekallinger;

• ny installasjon av appen;

• enhetsbytte;

• gjenoppretting av kjøp;

• endringer i tilstand uten brukerintervensjon.

BillingMeld isolerer denne logikken i en egen spesialisert lagrings- og verifiseringsprosess.

Produktservere arbeider med dette gjennom en felles kontrakt og trenger ikke å behandle alle særtrekk ved hver butikk selv.

Dette reduserer kode-duplisering og minimerer risikoen for at ulike applikasjoner i samme selskap tolker betalingsscenarier forskjellig.

Ikke sjekk, men aktuel rettighet

Det jeg synes er mest spennende med denne arkitekturen er overgangen fra å verifisere et enkelt kjøp til å kontrollere den aktuelle tilstanden.

Det faktum at en betaling for seg selv ikke svarer på det viktigste spørsmålet for produktet:

Har brukeren rett til funksjonen akkurat nå?

Kjøpet kan ha vært en vellykket initial transaksjon, men perioden kan være utløpt.

Abonnement kan ha deaktivert auto-forynelse, men fortsatt ha en betalt, aktiv periode.

Det kan være bekreftet fornyelse.

Det kan være en refundert operasjon.

Butikken kan ha trukket tilbake operasjonen.

Derfor er det den oppdaterte brukerrettigheten som er det essensielle, basert på bekreftet status.

Dette er hva BillingMeld formidler til andre tjenester.

BillingMeld som grensesnitt mellom butikker og produkter

Dette skaper en tydelig arkitektonisk grense.

Den ene siden har App Store og Google Play med sine formater, hendelser, regler og livssykluser.

Den andre siden er applikasjoner og interne tjenester som i stor grad bare trenger å vite hvilke rettigheter brukeren har nå.

Mellom dem plasseres BillingMeld.

Den tar butikkdata, verifiserer og konverterer dem til sin egen modell, og gir deretter resten av infrastrukturen en normalisert, oppdatert tilstand.

Dette gjør at produkter ikke trenger å kjenne alle detaljer ved hver betalingsplattform.

Hvorfor dette er viktig for brukeren

En riktig betalingsarkitektur bør i prinsippet være så godt som usynlig for brukeren.

Hvis kjøpet er bekreftet og den betalte perioden er aktiv, skal tilgangen fungere.

Hvis brukeren har deaktivert automatisk fornyelse, skal ikke den betalte perioden forsvinne før tid.

Hvis det skjer et nytt vellykket fornyelse, skal tilgangen fortsette.

Hvis butikken bekrefter refusjon eller tilbakekalling, bør systems tilstand oppdateres riktig.

Ved enhetsbytte eller reinstallasjon skal brukeren ikke trenge å dokumentere at kjøpet eksisterer for alle deler av infrastrukturen.

Det kan oppsummeres som en enkel regel:

Klienten rapporterer kjøpet, butikken er en ekstern kilde til tilstand, BillingMeld verifiserer og normaliserer denne tilstanden, og resten av infrastrukturen tar beslutningen på grunnlag av de pålitelige dataene fra BillingMeld.

Derfor er BillingMeld ikke bare en ekstra betalingsmodul, men et skybasert tillitsskjikt mellom mobilappen, App Store, Google Play, og produktene som trenger å ha en nøyaktig oversikt over hvilke betalte rettigheter brukeren har til enhver tid.

For mer informasjon om prosjektet, besøk: billingmeld.de.