BillingMeld: miks peaks ost ostma server kontrollima, mitte rakendus

Sisest kasutusmoodulis ostmine näib tavaliselt kasutajale lihtne. Ta vajutab nuppu, kinnitab makse, saab juurdepääsu funktsioonile või tellimusele ning ootab, et kõik töötab automaatselt edasi.

Arendaja jaoks algab aga palju keerulisem protsess. Tuleb kinnitada ost ise, arvestada pikendusi, tellimuse lõppemisi, tagastusi, tehingute ülevaateid, seadme muutmist ja erinevusi Apple ja Google poodide vahel.

Põhifunktsioon tekib siis, kui server hakkab usaldama kliendis rakendust tõe allikana.

Kui rakendus teatab: «Ost sooritatud», avab server juurdepääsu ning jätkab selle oleku alusel. Kuid ostutsükkel ei lõppe sellega.

Tellimus võib olla pikendatud, automaatne pikendamine võib olla välja lülitatud, makse võib olla tagastatud või tehing tühistatud poest.

Seetõttu kinnitab BillingMeld ostu mitte rakendus, vaid server.

Kliendi teatis – mitte otsus

BillingMeldi arhitektuuris ei ole mobiilirakendus peamine tehingu allikas.

Kliendid saavad edastada tehingu andmeid, kuid see on vaid põhjus kontrollimiseks. Lõplik otsus tehakse BillingMeldi serveripoolses osas, mis kontrollib infot Apple'i või Google'i infrastruktuuri kaudu.

See on fundamentaalne erinevus.

Rakendus telefonis võib töötada vanemate andmetega, mitte saada õigeaegselt uuendust või edastada andmeid, mis ei vasta hetke ostsituatsioonile.

Samuti ei tohiks klient ise otsustada, kas kasutajal on õigus tasulisele ligipääsule.

BillingMeld kontrollib näiteks:

• kas selline ost üldse eksisteerib;

• kas see on seotud õige rakenduse ja tootega;

• kas tasustatud periood on kehtiv praegu;

• kas on tehtud pikendus;

• kas automaatne pikendus on välja lülitatud;

• kas on tehtud tagastusi;

• kas operatsioon on tagasi võetud;

• kas tasutud periood on lõppemas.

Seega muutub kliendi teade mitte ostutõestuseks, vaid kutsuks selle tegeliku oleku kontrollimiseks.

Ainuõige allikas serveritele

Liidestatud teenustel ei ole vaja ise rakendada kogu integratsioonide komplekti Apple'i ja Google'iga korraga.

Nad pöörduvad BillingMeldi poole ja saavad juba normaliseeritud ostu oleku.

Näiteks: juurdepääs aktiivne, tasustatud periood lõppenud, pikendus kinnitatud, automaatne pikendus välja lülitatud või ost tühistatud.

See võimaldab selgelt jaotada vastutust.

Apple ja Google on ostutehingu seisundi allikad ise. BillingMeld kontrollib neid andmeid, normaliseerib need ühisele mudelile ning hoiab kehtivat olekut. Lõppkasutaja otsus ligipääsu kohta tehakse juba BillingMeldi oleku põhjal.

See tähendab, et toodete serverid kasutavad ühtset lepingut, mitte erinevaid sõltuvaid integratsioone.

Ei ole vaja iga teenuse puhul eraldi rakendada App Store'i ja Google Play'i reegleid ning seejärel püüda ühtlustada erinevaid vormateid, sündmusi ja olekuid ühise loogika alla.

Miks ei saa kliendile täielikult usaldada

Kliendirahendus töötab kasutaja seadmel.

Seda saab sulgeda, taaskäivitada, taastada varukoopiast, hiljem uuendada või uuel seadmel käivitada. See võib töötada koos vanemate andmetega või üldse mitte saada sündmust, mis toimus pärast esmast ostu.

Isegi kasutaja sekkumiseta on see klient halb allikas lõpliku staatuse määramisel.

Näiteks võis kasutaja sooritada tellimuse ja saada ligipääsu. Hiljem võib ost olla tühistatud või tõrke alla sattunud poest.

Kui server näeb ainult kliendi esmast teadet, peab ta arvama, et ost on kehtiv.

Teise olukorra korral võib kasutaja välja lülitada automaatse pikenduse. Sellisel juhul peab kehtiv olev periood jätkuma kuni selle lõppemiseni.

Kui süsteem kasutab lihtsat olekut «tellimus olemas / tellimust pole», võib ta liiga vara ligipääsu sulgeda või jätta selle avatuks, kuigi õigus on lõppemas.

BillingMeld põhineb teisel loogikal: klient ei kinnita oma õigusi. Ta teatab sündmustest, ning server määrab tegeliku ostu staatuse.

Ost on rohkem kui üks sündmus

Üks põhiviga arhitektuuris on käsitleda ostu kui ühekordset sündmust.

Tegelikult on sellel elutsükkel.

Esmalt ilmub tehing. Siis see kinnitatakse poest. Hakata võib tasutud perioodil. Hiljem võib toimuda järgmine pikendus.

Kasutaja võib välja lülitada automaatse pikenduse, kuid jätkata tellimuse kasutamist juba tasutud perioodil.

Makset võib järgmise pikenduse ajal ebaõnnestuda.

Võib olla tagastus tehingu kohta.

Võib olla tagasi võetud tehing.

Seetõttu ei piisa ainult teadmisest, et «see ost kunagi olemas oli».

Oluline on teada, mis selle ostuga praegu toimub.

Tagastus ja tühistamine ei jää märkamatuks

See on eriti oluline siis, kui on tegemist tagastuste ja tühistamistega.

Algne ost võis olla täiesti korrektne ja kasutaja maksnud ning saanud ligipääsu.

Kuid hiljem muutus tehingu seisund.

Kui BillingMeld saab info muudatustest, uuendab ta oma ostu oleku ning vajadusel kontrollib uuesti poest.

Pärast seda kasutab ühendatud teenus uut staatust.

Seeläbi ei usalda rakendus lõputult faktor, et paar nädalat või kuud tagasi teatas klient edukast ostust.

Kui pood ei arvesta enam õigust kehtivana, kajastab BillingMeld seda oma olekus.

Tellimuse tühistamine ja ligipääsu lõpp ei ole sama asi

Siin on oluline vahe.

Kui kasutaja on automaatse pikendamise välja lülitanud, ei tähenda see tavaliselt, et ligipääs tuleb kohe sulgeda.

Kehtiv tasustatud periood võib jätkata toimimist kuni lõppkuupäevani.

Sellisel juhul peab BillingMeld säilitama info, et edasine pikendus on välja lülitatud, ning samal ajal jälgima juba tasutud perioodi lõppkuupäeva.

Alles pärast selle lõppemist ei arvata, et ligipääs on aktiivne, kui uut kinnitatud pikendust ei ole toimunud.

See on üks põhjus, miks lihtne tõeväärtus subscription = true ei ole piisav normaalseteks arvutusteks.

Tellimuse olek on alati ajaga ja elutsükli sündmustega seotud.

Pikendus on samuti eraldi kontroll

Tellimus ei lõpe esimese maksega.

Server peab teadma, kas on toimunud järgmine pikendus ning kas järgnev tasustatud periood on tõesti kinnitatud poest.

BillingMeld jälgib selliseid muudatusi ja uuendab tellimuse olekut.

Kui pikendus on kinnitatud, jätkub ligipääs.

Kui makse ebaõnnestus või pood ei kinnita järgmist perioodi, ei tohiks süsteem lihtsalt pikendamist automaatselt teha.

Kasutajale näib see loomulik: ligipääs on kogu aeg nii kaua kui, kui tasutud periood kehtib.

See tähendab, et kordusprotsessi loogika ei pea iga rakenduse puhul uuesti üles ehitama.

Kuidas toimib tavapärane stsenaarium

Kasutaja teeb tellimuse mobiilirakenduses.

Kliendirakendus saab ostuteate ja edastab vajalikud andmed BillingMeldile. Kuid see ei ole veel piisav ostu lõplikuks kinnitamiseks.

BillingMeld kontrollib tehingu läbi vastava poe.

Kui App Store või Google Play kinnitab ostu ning selle olek vastab toote tingimustele, fikseeritakse aktiivne õigus.

Pärast seda annab ühendatud teenus kasutajale tasutud võimalused.

Olekk jätkab seejärel olemist sõltumata kliendi algsest teadest.

Kui tellimus pikendatakse, võetakse arvesse uus tasutud periood.

Kui kasutaja välja lülitab automaatse pikenduse, jätkub kehtiv periood kuni selle lõppemiseni.

Kui toimub tagastus või tehingut tühistatakse, muutub olek uuesti.

Selles skeemis ei säilita rakendus iseseisvat „tõest“ ning töötab olekuga, mis on kinnitatud ja salvestatud BillingMeldis.

Mida tähendab uue seadme kasutuselevõtt

Serveripõhine mudel on eriti kasulik, kui kasutaja vahetab telefoni või installib rakenduse uuesti.

Õigus ostu sooritada ei peaks sõltuma ainult sellest, kas konkreetne eksemplar oli kunagi edukas tehingu märgis.

Samuti ei tohiks rakenduse uuesti installimine tühistada kasutaja kinnitatud õigust.

Kui olek on salvestatud serveri poole ning seotud kinnitatud poe tehinguga, saab uus seade ammutada kehtiva staatuse serverilt.

See on veel üks põhjus, miks hoida ligipääsu loogika ainult mobiilirakendusest eemal, serveripoolne.

Mida see arendajatele annab

Kui arendusmeeskonda hallata mitu mobiilirakendust või kasutada samaaegselt iOS-i ja Androidi, muutuvalt maksete haldamine suureks infrastruktuuriväliseks ülesandeks.

Võimalik on arvestada:

• Apple ja Google erinevat formaat;

• esialgse ostu kinnitamine;

• pikenemised;

• tasutud perioodi lõpp;

• automaatse pikendi välja lülitamine;

• tagastused;

• operatsiooni tühistamine;

• rakenduse uuesti installimine;

• seadme vahetamine;

• ostude taastamine;

• oleku muutmine ilma kliendi osaluseta.

BillingMeld viib selle loogika eraldi spetsialiseeritud kihti.

Toote serverid töötavad sellega ühe lepinguga ning ei peaks ise iga poodide eripära tõlgendama.

See vähendab koodi dubleerimist ning mis veelgi olulisem, vähendab riski, et erinevad rakendused samas ettevõttes kannavad erinevat arusaama ühest ja samast maksesündmusest.

Miks ei ole oluline ainult kontroll, vaid õigused

Seda arhitektuuri sügavama huvi tekitab üleminek kontrollimisel ostu kui oleva staatuse jälgimisele.

Ajalooliselt ei vasta makse- või ostutegevuse tõend endale küsimusele:

kas kasutajal on praegu õigus kasutada tasulist funktsiooni?

Kuigi tehingus võib olla edukas esimene ost, võib periood juba lõppeda.

Tellimus võib olla välja lülitatud automaatne pikendus, kuid juba tasustatud periood võib veel kehtida.

Võib olla kinnitatud pikendus.

Võib olla tehtud tagastus.

Poeg võib tehingu tagasi võtta.

Seega on peamine mitte kinnitus ega algne klientiivne vastus, vaid kasutaja kehtiv õigustus, mis põhineb ostu kinnitatud seisundil.

Seda olekut edastab BillingMeld teistele teenustele.

BillingMeld kui tõe piir

Selle tulemusena tekib selge arhitektuuriline piir.

Ühel küljel on App Store ja Google Play oma formaadide, sündmuste, reeglite ning elutsüklitega.

Teisel pool on rakendused ja siseteenused, kellele on ennekõike vajalik lihtne vastus: millised õigused on kasutajal hetkel?

Selles vahepeal paikneb BillingMeld.

See võtab vastu poodide andmed, kontrollib neid, viib need enda mudelisse ning pakub teistele infrastruktuuridele juba normaliseeritud tulemust.

See võimaldab toodetel mitte teada iga maksete platvormi spetsiifikat ja keerukust.

Miks see on kasulik kasutajale

Kasutajale peaks korrektne maksete arhitektuur olema praktiliselt märkamatuks jääv.

Kui ost on kinnitatud ja tasustatud periood kehtib, töötab ligipääs.

Kui kasutaja välja lülitab automaatse pikenduse, ei tohiks juba tasutud aeg enne perioodi lõppu kaduda.

Kui toimub uus kinnitatud pikendus, peaks ligipääs jätkuma.

Kui pood kinnitab tagastuse või tühistamise, peaks süsteem vastavalt muutma kasutaja õigusi.

Seadme vahetusel või uuesti installimisel ei peaks kasutaja käsitsi tõestama, et ost on tõepoolest olemas.

Lõppkokkuvõttes jääb reegel üsna lihtsaks:

klient teatab ostust, pood on välise allikana selle staatuse, BillingMeld kontrollib ja normaliseerib selle ning lõpuks teevad teised teenused otsused, tuginedes juba kinnitatud andmetele BillingMeldist.

Seetõttu ei ole BillingMeld lihtsalt üks makseüksus, vaid usaldusserver, mis on vahepeal mobiilirakenduse, Apple ja Google poodide ning toodete vahel, kellel on vaja teadmist, millised tasulised õigused hetkel kehtivad.

Lisateave: billingmeld.de.