BillingMeld: zakaj mora preveriti nakup strežnik, ne aplikacija

Nakup znotraj mobilne aplikacije običajno izgleda preprost za uporabnika. Klikne na gumb, potrdi plačilo, pridobi dostop do funkcije ali naročnine — in pričakuje, da bo vse od zdaj samodejno delovalo.

Za razvijalca pa za tem gumbom začne veliko bolj zapleten proces. Potrebno je potrditi sam nakup, upoštevati podaljšanja, konec naročnine, vračila, preverjati operacije, spremembe naprave in razlike med trgovinama Apple in Google.

Glavna težava nastane, ko strežnik začne šteti, da je od uporabniške aplikacije odvisen vir resnice.

Če aplikacija sporoči: »Nakup opravljen«, strežnik odpre dostop in nadaljuje z izvajanjem na podlagi enkrat prejetega stanja. A vendar življenjski cikel nakupa na tem še ni končan.

Nakup lahko bo podaljšan, samodejno podaljšanje je lahko onemogočeno, plačilo je lahko vrnjeno, sama operacija pa je lahko preklicana s strani trgovine.

Zato BillingMeld potrdi nakup ne aplikacija, temveč strežnik.

Stranka sporoča, a ne odloča

V arhitekturi BillingMeld mobilna aplikacija ni glavni vir informacij o nakupu.

Stranka lahko posreduje podatke o opravljenem procesu, vendar je to le osnova za preverjanje. Končno odločitev sprejme strežniški del BillingMeld, ki informacije preveri preko infrastrukture Apple ali Google.

To je temeljna razlika.

Aplikacija na telefonu lahko deluje s starim stanjem, ne prejme pravočasno naslednje spremembe ali posreduje podatke, ki že ne ustrezajo trenutnemu stanju nakupa.

Poleg tega stranka ne bi smela imeti možnosti, da sama odloča, ali uporabniku pripada plačljiv dostop.

BillingMeld preveri, na primer:

• ali sploh obstaja tak nakup;

• ali se nanaša na pravi aplikacijo in izdelek;

• ali je plačani čas trenutno aktiven;

• ali je bila izvedena naslednja podaljšanja;

• ali je onemogočeno naslednje samodejno podaljšanje;

• ali je bilo opravljeno vračilo;

• ali je bila operacija preklicana;

• ali plačani čas še ni potekel.

Na ta način se sporočilo od stranke ne šteje za dokaz nakupa, temveč kot razlog za preverjanje njegovega dejanskega stanja.

Eni vir resnice za strežnike

S povezanim storitvam ni potrebna samostojna implementacija polnega niza integracij z Apple in Google hkrati.

Obračajo se na BillingMeld in dobijo že normalizirano stanje nakupa.

Na primer: dostop je aktiven, plačani čas je potekel, naslednje podaljšanje je potrjeno, samodejno podaljšanje je onemogočeno ali je nakup preklican.

To omogoča jasen razdelitev odgovornosti.

Apple in Google sta vir stanja trgovske operacije. BillingMeld preveri te podatke, jih združi v skupni model in shrani aktualno stanje. Končni produkt na podlagi stanja BillingMeld odloča o dostopu.

Za strežnike produktov to pomeni enoten pogodbeni dogovor namesto več ločenih integracij.

Ni treba posebej implementirati pravil App Store, Google Play, ter poskušati uskladiti različne formate, dogodke in statuse v skupno logiko.

Zaupati stranki v celoti ni mogoče

Strankina aplikacija deluje na uporabnikovi napravi.

Lahko jo zapre, ponovno zažene, obnovi iz varnostne kopije, kasneje posodobi ali zažene na drugi napravi. Lahko nekaj časa deluje s starimi podatki ali sploh ne prejme dogodka, ki se je zgodil po prvotnem nakupu.

Tudi brez kakršnegakoli posega uporabnika to naredi stranko slabo zanesljiv vir končnega stanja naročnine.

Na primer, uporabnik je sklenil naročnino in pridobil dostop. Kasneje je bilo opravljeno vračilo ali trgovina je preklicala operacijo.

Če strežnik ve samo o prvem sporočilu stranke, bo še naprej štel, da je nakup veljaven.

V drugi situaciji lahko uporabnik onemogoči samodejno podaljšanje. Pri tem že plačani čas naj še vedno ostaja aktiven do datuma zaključka.

Če sistem obravnava le primitivno stanje »naročnina obstaja / ni«, bo dostop prehitro zaprl ali ga bo prepozno pustil, da poteče, kljub pravici do nadaljevanja uporabe.

BillingMeld temelji na drugi logiki: stranka ne potrdi svojih pravic. Ona sporoči dogodek, strežnik pa določi dejansko stanje nakupa.

Nakup ni en dogodek

Ena izmed glavnih napak v arhitekturi zaračunavanja je obravnavanje nakupa kot enega samega dogodka.

Dejstvo pa je, da ima nakup življenjski cikel.

Najprej nastane operacija. Nato jo trgovina potrdí. Za naročnino začne veljati plačan period. Kasneje je lahko izvedeno naslednje podaljšanje.

Uporabnik lahko onemogoči samodejno podaljšanje, a še naprej uporablja naročnino do konca plačanega obdobja.

Plačilo je lahko neuspešno pri naslednjem podaljšanju.

Se lahko zgodi vračilo.

V nekaterih primerih lahko nakup tudi prekličejo.

Zato en sam podatek »ta nakup je bil nekoč opravljen« ni dovolj.

Strežnik mora razumeti, kaj se z nakupom dogaja zdaj.

Vračilo nakupa ne ostaja neopaženo

Posebej je to vidno pri vračilih in preklicih operacij.

Prvotni nakup je bil lahko povsem pravilen. Uporabnik je plačal za izdelek in imel dostop.

Vendar je stanje operacije kasneje spremenjeno.

Če BillingMeld prejme informacijo o spremembi, posodobi lastno stanje nakupa in, če je treba, preveri podatke preko trgovine.

Nato povezane storitve že delujejo z novim statusom.

Na ta način aplikacija ne sme več neskončno zaupati dejstvu, da je uporabnik pred časom sporočil uspešen nakup.

Če trgovina več ne šteje pravice za veljavno, BillingMeld to odraža v svojem stanju.

Preklic naročnine in opustitev dostopa nista enaka

Tu obstaja pomembna razlika.

Če je uporabnik onemogočil samodejno podaljšanje naročnine, to običajno ne pomeni, da se dostop takoj zapre.

Trenutno plačani čas lahko še vedno velja.

V takem primeru mora BillingMeld shraniti informacijo, da je nadaljnje podaljšanje onemogočeno, hkrati pa zagotoviti datum zaključka že plačanega obdobja.

Šele po izteku tega obdobja dostop preneha veljati, če ni bilo potrjenega novega podaljšanja.

To je eden od razlogov, zakaj enostavno bool vrednost subscription = true za običajno zaračunavanje ni dovolj.

Stanje naročnine je vedno povezano s časom in dogodki njenega življenjskega cikla.

Podaljšanje je tudi samostojno preverjanje

Naročnina se ne konča pri prvi plačilu.

Strežnik mora razumeti, ali je prišlo do naslednjega podaljšanja in ali je naslednji plačani čas res potrjen s strani trgovine.

BillingMeld spremlja takšne spremembe in posodablja stanje naročnine.

Če je podaljšanje potrjeno, pravico do dostopa se podaljšuje.

Če naslednje obračunavanje ni bilo uspešno ali trgovina ne potrdi naslednjega obdobja, sistem ne sme na podlagi preprostega predpostavljanja podaljšati dostopa.

To uporabniku daje občutek, da dostop traja toliko časa, kot velja plačana naročnina.

Za razvijalce to pomeni, da isto logiko podaljšanja ni treba vsakič posebej implementirati v vsaki aplikaciji.

Kakšen je običajen scenarij

Uporabnik sklene naročnino v mobilni aplikaciji.

Stranka prejme podatke o nakupu in posreduje potrebne informacije BillingMeld. Vendar ta sporočilo še ni dokončni dokaz, da je nakup potrjen.

BillingMeld preveri operacijo preko ustrezne trgovine.

Če App Store ali Google Play potrdi nakup in njegovo stanje ustreza pravilom izdelka, BillingMeld zabeleži aktivno pravico.

Nato povezano podjetje uporabniku zagotovi plačane funkcije.

Stanje od tega trenutka naprej deluje neodvisno od prvotnega sporočila stranke.

Če se naročnina podaljša, BillingMeld upošteva nov plačani čas.

Če uporabnik onemogoči samodejno podaljšanje, trenutni čas še vedno velja do njegovega zaključka.

Če pride do vračila ali preklica operacije, se stanje spet spremeni.

V tej shemi aplikacija ne hrani lastne »resnice« o nakupu. Deluje s stanjem, ki ga potrdi in shrani BillingMeld.

Kaj se zgodi pri menjavi naprave

Strogo arhitekturo osebno posebej koristi, če uporabnik zamenja telefon ali ponovno znova namesti aplikacijo.

Pravica do nakupa ne sme obstajati samo zato, ker je določen primerki aplikacije nekoč videl uspešen transakcijo.

Nasprotno, ponovna namestitev aplikacije ne sme uničiti potrjenega pravice uporabnika.

Če je stanje nakupa na strežniku in povezano z potrjeno trgovsko operacijo, lahko novo napravo pridobi aktualno stanje preko strežnika.

To je še en razlog, zakaj nepravilno, da je logika dostopa odvisna le od mobilnega klienta.

Kaj to razvijalcem omogoča

Za ekipo, ki izdaja več mobilnih aplikacij ali deluje na iOS in Android hkrati, zaračunavanje hitro postane ločena infrastrukturna naloga.

Treba je upoštevati:

• različne formate podatkov Apple in Google;

• potrditev prvotnega nakupa;

• podaljšanja naročnin;

• konec plačanega obdobja;

• onemogočenje samodejnega podaljšanja;

• vračila;

• prekličevanja operacij;

• ponovno namestitev aplikacije;

• zamenjavo naprave;

• obnovitev nakupov;

• spremembo stanja brez sodelovanja uporabnika.

BillingMeld ta logika prenese v poseben sloj.

Strežniki produktov z njim delujejo po enotni pogodbi in se ne smejo sami interpretirati navodil za vsako trgovino.

S tem se zmanjša možnost dvojne kode in hkrati zmanjša tveganje, da bi različne aplikacije iste družbe različno razumele isti plačilni scenarij.

Ključ ni račun, temveč aktualno pravico

Največ kar me je v tej arhitekturi zanimalo, je prehod od preverjanja enega samega nakupa k kontroli aktualnega stanja.

Zgodovinski podatek o plačilu nam še ni odgovoril na glavno vprašanje produkta:

ali ima uporabnik v tem trenutku pravico do plačljive funkcije?

Operacija lahko ima uspešno prvo nakupno, vendar že potekli period.

Naročnina ima lahko onemogočeno samodejno podaljšanje, a še vedno velja že plačani rok.

Obstaja lahko potrjeno podaljšanje.

Obstaja lahko vračilo.

Trgovina lahko prekliče operacijo.

Zato je glavni element pravica uporabnika, izračunana na podlagi potrjenega stanja nakupa.

Ta stanju posreduje BillingMeld drugim storitvam.

BillingMeld kot meja med trgovinami in produkti

Z nesporne rezultate se pojavi precej jasna arhitekturna meja.

S strani je App Store in Google Play s svojimi formati, dogodki, pravili in življenjskimi cikli nakupov.

Z druge strani — aplikacije in notranje storitve, ki v večini primerov potrebujejo veliko bolj preprost odgovor: kakšna pravica je uporabniku v tem trenutku.

Med njima je BillingMeld.

Sprejema podatke trgovin, jih preveri, združi v svoj model in nato zagotovi še preostali infrastrukturi že normaliziran rezultat.

Zato produktom ni treba poznati vseh notranjih posebnosti vsake plačilne platforme.

Zakaj je to pomembno za uporabnika

Za uporabnika mora biti pravilna zaračunovalna arhitektura v idealnem primeru povsem neopazna.

Če je nakup potrjen in plačani čas še velja, mora dostop delovati.

Če je uporabnik onemogočil nadaljnje podaljšanje, se že plačani rok ne sme predčasno iztekati.

Če je prišlo do novega uspešnega podaljšanja, mora dostop ostati aktiven.

Če je trgovina potrdila vračilo ali preklic, sistem mora pravilno odraziti spremembo pravice.

Pri menjavi naprave ali ponovni namestitvi aplikacije uporabniku ni treba ročno dokazovati vsaki sestavini infrastrukture, da nakup res obstaja.

Na koncu je pravilo preprosto:

stranka sporoči nakup, trgovina je zunanji vir njegovega stanja, BillingMeld preveri in normalizira to stanje, ostale storitve pa odločajo na podlagi potrjenih podatkov BillingMeld.

Zato BillingMeld ni le še en modul za plačilo.

Je strežniški sloj zaupanja med mobilno aplikacijo, trgovinami Apple in Google ter produkti, ki morajo natančno vedeti, katera plačljiva pravice trenutno pripadajo uporabniku.

Več informacij o projektu: billingmeld.de.