BillingMeld: kodėl pirkimą turi patvirtinti serveris, o ne programa

Mobiliojoje programėlėje įsigijimas dažnai atrodo paprastas vartotojui. Jis paspaudžia mygtuką, patvirtina mokėjimą, gauna prieigą prie funkcijos arba prenumeratos – ir tikisi, kad visi kiti veiksmai vyks automatiškai.

Programuotojui už šio mygtuko prasideda daug sudėtingesnis procesas. Reikia patvirtinti pačią pirkimo operaciją, sekti jos pratęsimus, pabaigos datą, grąžinimus, operacijų atsiliepimus, įrenginio keitimą ir skirtumus tarp Apple ir Google parduotuvių.

Pagrindinė problema iškyla tada, kai serveris pradeda teigti, kad klientinė programėlė yra tiesos šaltinis.

Jeigu programa praneša: „Pirkimas įvykdytas“, serveris atveria prieigą ir toliau remiasi viena kartą gauta būsenos informacija. Tačiau pirkimo gyvavimo ciklas tuo nesibaigia.

Prenumerata gali būti pratęsta, automatinis pratęsimas gali būti išjungtas, mokėjimas gali būti grąžintas, o pati operacija – atšaukta parduotuvės.

Štai kodėl BillingMeld pirkimą patvirtina ne programa, o serveris.

Klientas praneša, bet ne sprendžia

BillingMeld architektūroje mobilioji programa nėra pagrindinis informacijos apie pirkimą šaltinis.

Klientas gali perduoti duomenis apie atliktą operaciją, tačiau tai tik pagrindas tikrinti. Galutinį sprendimą priima BillingMeld serverio dalis, kuri patikrina duomenis per Apple ar Google infrastruktūrą.

Tai esminis skirtumas.

Telefono programėlė gali dirbti su sena būsena, neprarasti naujų pakeitimų laiku arba perduoti duomenis, kurie jau neatitinka dabartinės pirkimo būsenos.

Be to, klientas neturi turėti galimybės savarankiškai nuspręsti, ar naudotojui priklauso mokama prieiga.

BillingMeld patikrina, pavyzdžiui,:

• ar tokia pirkimo operacija tikrai egzistuoja;

• ar ji susijusi su konkrečia programa ir produktu;

• ar dabar galioja apmokėta laikotarpis;

• ar įvyko naujas pratęsimas;

• ar išjungtas tolesnis automatinis pratęsimas;

• ar buvo atliktas grąžinimas;

• ar operacija buvo atšaukta;

• ar galiojimo laikotarpis nėra pasibaigęs.

Taigi kliento pranešimas nėra pirkimo įrodymas, o pagrindas patikrinti jos būseną.

Vieningas tiesos šaltinis serveriams

Prisijungusios paslaugos nereikia patiems įgyvendinti pilno integravimo su Apple ir Google.

Jie kreipiasi į BillingMeld ir gauna jau normalizuotą pirkimo būseną.

Pavyzdžiui: prieiga aktyvi, apmokėtas laikotarpis pasibaigė, pratęsimas patvirtintas, automatinis pratęsimas išjungtas arba pirkimas atšauktas.

Tai leidžia aiškiai paskirstyti atsakomybę.

Apple ir Google yra sąsajos su parduotuvės operacijos būsenos šaltiniais. BillingMeld patikrina šiuos duomenis, juos sutvarko į bendrą modelį ir išsaugo aktualią būseną. O galutinė prieiga sprendžiama pagal BillingMeld būseną.

Produktų serveriams tai reiškia vieningą kontraktą, o ne kelių nepriklausomų integracijų.

Nereikia kiekviename serveryje įgyvendinti atskirų App Store ir Google Play taisyklių, vėliau bandyti suderinti skirtingus formatų, įvykių ir būsenų duomenis į bendrą logiką.

Kodėl klientui negalima visiškai pasitikėti

Klientinė programa veikia naudotojo įrenginyje.

Jį galima uždaryti, perkrauti, atkurti iš atsarginės kopijos, vėliau atnaujinti ar paleisti kitame įrenginyje. Ji gali laikyti senus duomenis arba neprarasti įvykusių naujų įvykių.

Be vartotojo įsikišimo, tai daro klientą prastu galutinio būsenos šaltiniu.

Pavyzdžiui, naudotojas įsigijo prenumeratą ir gavo prieigą. Vėliau pirkimas buvo grąžintas arba operacija atšaukta parduotuvės.

Jei serveris žino tik apie pirminį kliento pranešimą, jis toliau laikys pirkimą galiojančiu.

Kitoje situacijoje naudotojas gali išjungti automatinį pratęsimą. Tuomet jau apmokėtas laikotarpis vis dar turi būti aktyvus iki jo pabaigos.

Jei sistema naudoja tik paprastą būsenos „prenumerata yra / nėra“ modelį, ji gali per anksti uždaryti prieigą arba palikti ją teisiškai pasibaigus.

BillingMeld pagrįsta kita logika: klientas nepateikia savo teisių patvirtinimo. Jis praneša apie įvykį, o serveris nustato faktinę pirkimo būseną.

Pirkimas – tai ne vienas įvykis

Viena iš dažnų klaidų billing architektūroje – laikyti pirkimą kaip vieną įvykį.

Iš tikrųjų, ji turi gyvavimo ciklą.

Pradžioje įvyksta operacija. Tada ji patvirtinama parduotuvės. Pradedamas apmokėtas laikotarpis. Vėliau gali būti pratęsimas.

Naudotojas gali išjungti automatinį pratęsimą, tačiau vis tiek naudotis prenumerata iki apmokėto laikotarpio pabaigos.

Mokėjimas gali nepavykti vėlesnio pratęsimo metu.

Gali būti atliktas grąžinimas.

Aptarnaujamais atvejais pirkimas gali būti atšauktas.

Todėl vien faktas „šiai pirkimai kadaise buvo“ nėra pakankamas.

Svarbu, kad serveris žinotų, kas vyksta dabar.

Grąžinimas ir atšaukimas – nėra nepastebimi

Ypač ryškiai to matyti grąžinimų ir atsiėmimų atvejais.

Pirmosios pirkimo operacijos būklė galėjo būti visiškai tvarkinga. Naudotojas iš tikrųjų sumokėjo ir gavo prieigą.

Tačiau vėliau operacijos būsena pasikeitė.

Jei BillingMeld gauna duomenis apie būsenos pasikeitimą, jis atnaujina savo pirkimo būseną ir, jei reikia, papildomai tikrina duomenis parduotuvėje.

Po to prisijungęs servis tapo su nauja būsena.

Taip programa nesibaigs besąlygiškai pasitikėti faktu, kad kelių savaičių ar mėnesių senumo klientas kartą pranešė apie sėkmingą pirkimą.

Jeigu parduotuvė nebelaiko teisės galiojančia, BillingMeld tai atvaizduoja savo būsenoje.

Atšaukimas ir prieigos pabaiga nėra tas pats

Čia yra svarbus skirtumas.

Jeigu vartotojas išjungia automatinį prenumeratos pratęsimą, tai dažnai nereiškia, kad prieiga turi būti nedelsiant uždaryta.

Esamas apmokėtas laikotarpis gali toliau galioti.

Tada BillingMeld turi įrašyti, kad tolesnis pratęsimas išjungtas, bet kartu žinoti apie esamos apmokėtos laikotarpio pabaigą.

Ir tik pasibaigus šiam laikotarpiui, prieiga nėra aktyvi, jei neįvyko naujas patvirtinimas.

Tai yra vienas iš pavyzdžių, kodėl vieno loginio parametro subscription = true nepakanka geram billygui.

Prenumeratos būseną visada gali lemti laikas ir įvykiai, įvykiai gyvavimo ciklo metu.

Pratęsimas – tai irgi atskira patikra

Prenumerata nesibaigia su pirma mokėjimo operacija.

Serveris turi matyti, ar įvyko naujas pratęsimas, ir ar jis yra tikrai patvirtintas parduotuvės.

BillingMeld stebi tokius pokyčius ir atnaujina būseną.

Jeigu pratęsimas patvirtintas, prieiga išlieka.

Jeigu apmokestinimas nesėkmingas arba parduotuvė nepatvirtina kito periodo, sistema neturėtų tiesiog pratęsti prieigos remiantis tik spėjimu.

Naudotojui tai atrodo natūraliai: prieiga egzistuoja tiek, kiek veikia apmokėta prenumerata.

Programuotojams tai reiškia, kad vienos ir tos pačios prieigos pratęsimo logikos nereikia įgyvendinti kiekvienoje programėlėje iš naujo.

Kaip atrodo įprastas scenarijus

Naudotojas įsigyja prenumeratą mobiliąjame programėle.

Klientas gauna duomenis apie pirkimą ir perduoda reikalingus duomenis BillingMeld. Tačiau pats šis pranešimas dar nereiškia, kad pirkimas galutinai patvirtintas.

BillingMeld patikrina operaciją per atitinkamą parduotuvę.

Jeigu App Store ar Google Play patvirtina pirkimą ir jo būsena atitinka produkto reikalavimus, BillingMeld užfiksuoja aktyvią teisę.

Tada prisijungęs servisas suteikia naudotojui apmokėtas galimybes.

Vėliau būsenos pokyčiai vyksta nepriklausomai nuo kliento pranešimo.

Jeigu prenumerata pratęsiama, BillingMeld atnaujina naują apmokėtą laikotarpį.

Jeigu naudotojas išjungia automatinį pratęsimą, dabartinis laikotarpis gali toliau galiooti iki pabaigos.

Jeigu įvyksta grąžinimas ar atšaukimas, būsena vėl keičiasi.

Šiame modelyje programa nesudaro savo atskiros „tiesos“ apie pirkimą. Ji dirba su būseną, kuri patvirtinta ir išsaugota BillingMeld.

Ką reiškia pokytis įrenginyje

Serverinė modelis ypač naudinga, kai naudotojas keičia telefoną ar įdiegia programėlę iš naujo.

Teisė į pirkinį neturėtų egzistuoti vien todėl, kad konkretus modelis kada nors matė sėkmingą operaciją.

Atvirkščiai, programėlės perdiegimas neturėtų naikinti patvirtintos naudotojo teisės.

Jeigu pirkimo būsena yra serveryje ir susieta su patvirtinta parduotuvės operacija, naujas įrenginys gali gauti naujausią būseną per serverį.

Tai dar vienas argumentas, kodėl nereikia valdyti prieigos tik mobiliojo kliento lygyje.

Kaip tai naudinga programuotojams

Komandai, kuri kuria kelias mobiliąsias programas ar dirba su iOS bei Android, billing greitai tampa infrastruktūros dalimi.

Reikia atsižvelgti į:

• skirtingus Apple ir Google duomenų formatus;

• pirminio pirkimo patvirtinimą;

• pratęsimo procesus;

• mokėjimo pabaigą;

• automatinio pratęsimo išjungimą;

• grąžinimus;

• operacijų atšaukimus;

• programėlės perkrovimus;

• įrenginio keitimą;

• pirkimo atstatymus;

• ir būsenos pokyčius be naudotojo dalyvavimo.

BillingMeld iškelia šią logiką į atskirą specializuotą sluoksnį.

Produktų serveriai dirba su juo pagal vieningą kontraktą ir patys nes privalo interpretuoti kiekvieno parduotuvės niuansus.

Tai sumažina dubliuojamo kodo kiekį ir, svarbiausia, sumažina riziką, kad keli to paties įmonės programėlės bus skirtingai suprantamos apie tą patį mokėjimo scenarijų.

Svarbiausias ne čekis, o teise

Man šioje architektūroje labiausiai patiko perėjimas nuo vienkartinio pirkimo patikrų prie nuolatinės būsenos kontrolės.

Istorinė mokėjimo faktas pats savaime neatsako į svarbiausią produkto klausimą:

ar naudotojui dabar priklauso mokama funkcija?

Operacijai gali būti sėkmingas pradinis pirkimas, bet pasibaigęs laikotarpis.

Gali būti išjungtas automatinis pratęsimas, tačiau jau mokėtas laikotarpis vis dar galioja.

Gali būti patvirtintas pratęsimas.

Gali būti atliktas grąžinimas.

Parduotuvė gali atšaukti operaciją.

Dėl to pagrindiniu objektu tampa ne čekis ir ne pradinis kliento atsakymas, o naudotojo teisė, pagrįsta patvirtinta pirkimo būsena.

Šią būseną BillingMeld perduoda kitiems servisams.

BillingMeld kaip tiltas tarp parduotuvių ir produktų

Gaunasi gana aiški architektūros riba.

Iš vienos pusės – App Store ir Google Play su savo formatais, įvykiais, taisyklėmis ir gyvavimo ciklais.

Iš kitos – programėlės ir vidiniai servisai, kuriems dažniausiai reikia paprastesnio atsakymo: kokios teisės naudotojui dabar priklauso.

Tarp jų – BillingMeld.

Jis priima parduotuvių duomenis, patikrina juos, sutvarko į savo modelį ir pateikia likusiai infrastruktūrai jau normalizuotą rezultatą.

Taip produktai nereikia žinoti visų vidinių kiekvienos mokėjimo platformos niuansų.

Kodėl tai naudinga naudotojui

Naudotojui teisinga billygų architektūra idealioje situacijoje turėtų būti nesimatyti.

Jeigu pirkimas patvirtintas ir galioja mokėtas laikotarpis, prieiga turi veikti.

Jeigu naudotojas išjungė automatinį pratęsimą, apmokėtas laikotarpis neturi baigtis anksčiau laiko.

Jeigu įvyksta naujas pratęsimas, prieiga turi būti tęsiama.

Jeigu parduotuvė patvirtina grąžinimą ar atšaukimą, sistema turėtų teisingai atvaizduoti naudotojo teisių pasikeitimą.

Nepageidaujant, keisti galiojančią būseną ar papildyti ją nereikėtų naudotojui galvos skausmo ar papildomo darbo.

Išvada paprasta: klientas praneša apie pirkimą, parduotuvė yra išorinis jos būsenos šaltinis, BillingMeld patvirtina ir normalizuoja šią būseną, o kiti servisai priima sprendimus remdamiesi patvirtintais duomenimis.

Todėl BillingMeld nėra tik dar vienas apmokėjimo modulis.

Jis – serverio sluoksnis pasitikėjimo tarp mobiliosios programėlės, Apple ir Google parduotuvių bei pačių produktų, kuriems būtina tiksliai žinoti, kokios mokamos teisės šiuo metu priklauso naudotojui.

Daugiau apie projektą: billingmeld.de.