BillingMeld: zašto provjeru kupnje obavlja poslužitelj, a ne aplikacija

Unutarnja kupnja unutar mobilne aplikacije obično izgleda jednostavno samo za korisnika. Klikne na gumb, potvrdi uplatu, dobije pristup funkciji ili pretplati — i očekuje da će dalje sve raditi automatski.

Za programere, iza tog gumba počinje znatno složeniji proces. Potrebno je potvrditi samu kupnju, uzeti u obzir produljenja, završetak pretplate, povrate, recenzije operacija, promjenu uređaja i razlike između trgovina Apple i Google.

Glavni problem nastaje kada server počne smatrati da je klijentska aplikacija izvor istine.

Ako aplikacija javlja: „Kupnja izvršena“, server omogućava pristup i nastavlja se oslanjati na jednom dobivenom stanju. No, životni ciklus kupnje tu ne završava.

Pretplata može biti produljena, automatsko produljenje može biti isključeno, uplata može biti vraćena, a sama operacija može biti povučena trgovinom.

Zato BillingMeld potvrdu kupnje provodi server, a ne aplikacija.

Korisnik javlja, ali ne odlučuje

U arhitekturi BillingMeld, mobilna aplikacija nije glavni izvor informacija o kupnji.

Korisnik može poslati podatke o izvršene operaciji, ali to je samo osnova za provjeru. Konačnu odluku donosi serverski dio BillingMeld, koji provjerava informacije putem infrastrukture Apple ili Google.

To je principijelna razlika.

Mobitel može raditi sa starim stanjem, ne dobiti pravovremeno najnoviju promjenu ili poslati podatke koji više nisu u skladu s trenutnim stanjem kupnje.

Osim toga, korisnik ne bi trebao samostalno odlučivati hoće li imati pravo na plaćeni pristup.

BillingMeld provjerava, na primjer:

• stvarno li postoji takva kupnja;

• odnosi li se na željenu aplikaciju i proizvod;

• je li plaćeni period trenutno aktivan;

• je li došlo do produljenja;

• je li isključeno daljnje automatsko produljenje;

• je li izvršen povrat;

• je li operacija povučena;

• je li plaćeni period još uvijek aktivan.

Na taj način, poruka klijenta više nije dokaz o kupnji, već razlog za provjeru njezina stvarnog stanja.

Jedinstveni izvor istine za poslužitelje

Povezane usluge ne trebaju samostalno implementirati cijeli skup integracija s Apple i Google u isto vrijeme.

One se obraćaju BillingMeld-u i dobivaju već normalizirano stanje kupnje.

Na primjer: pristup je aktivan, plaćeni period je istekao, produljenje je potvrđeno, automatsko produljenje je isključeno ili je kupnja povučena.

To omogućava jasnu podjelu odgovornosti.

Apple i Google su izvori stanja same trgovinske operacije. BillingMeld provjerava te podatke, usklađuje ih s zajedničkim modelom i održava ažurirano stanje. Završni proizvod odlučuje o pristupu na temelju statusa BillingMeld-a.

Za servere proizvoda to znači jedinstveni ugovor umjesto više neovisnih integracija.

Ne treba zasebno implementirati pravila App Store i Google Play, a zatim pokušavati uskladiti različite formate, događaje i statuse u zajedničku logiku.

Zašto ne smije u potpunosti vjerovati klijentu

Klijentska aplikacija radi na uređaju korisnika.

Može se zatvoriti, ponovno pokrenuti, vratiti iz sigurnosne kopije, kasnije ažurirati ili pokrenuti na drugom uređaju. Može neko vrijeme raditi sa starim informacijama ili uopće ne dobiti događaj koji se dogodio nakon prvobitne kupnje.

Čak i bez intervencije korisnika, to čini klijent lošim izvorom konačnog stanja pretplate.

Na primjer, korisnik je napravio pretplatu i dobio pristup. Kasnije je došlo do povrata ili trgovina je povukla operaciju.

Ako server zna samo o početnom poruci klijenta, nastavit će smatrati kupnju važećom.

U drugoj situaciji, korisnik može isključiti automatsko produljenje. Unatoč tome, već plaćeni period i dalje bi trebao ostati aktivan do svog završetka.

Ako sustav koristi samo jednostavno stanje „pretplata je / nema pretplate“, lako može prerano zatvoriti pristup ili ga, naprotiv, ostaviti nakon isteka prava korištenja.

BillingMeld gradi na drugačijoj logici: klijent ne potvrđuje svoja prava; on javlja o događaju, a server određuje stvarno stanje kupnje.

Kupnja — to nije jedno događanje

Jedna od glavnih pogrešaka u arhitekturi plaćanja jest smatrati kupnju kao jedinstveni događaj.

U stvari, ona ima svoj životni ciklus.

Najprije nastaje operacija. Zatim je potvrđuje trgovina. Za pretplatu počinje plaćeni period. Kasnije može doći do produljenja.

Korisnik može isključiti automatsko produljenje, ali i dalje koristiti pretplatu do kraja već plaćenog razdoblja.

Sljedeće produženje može biti blokirano ili odobreno.

Pojavljuje se povrat ili povlačenje operacije.

Zbog toga, samo činjenica da je kupnja nekada postojala nije dovoljna.

Server mora znati što se s njom trenutno događa.

Povlačenje kupnje ne ostaje nezamijećeno

Posebno je jasno zašto je potrebno serversko okruženje kod povrata i povlačenja operacija.

Prva kupnja mogla je biti savršeno valjana. Korisnik je doista platio i dobio pristup.

Ali kasnije je stanje operacije promijenjeno.

Ako BillingMeld primi izmjenu, on ažurira vlastito stanje kupnje i, po potrebi, dodatno provjerava podatke putem trgovine.

Nakon toga, povezana usluga radi s novim statusom.

Na taj način, aplikacija ne nastavlja beskonačno vjerovati u činjenicu da je prije nekoliko tjedana ili mjeseci korisnik jednom prijavio uspješnu kupnju.

Ako trgovina više ne smatra da je pravo aktivno, BillingMeld to odražava u svom stanju.

Otkupljivanje pretplate i kraj pristupa — nisu isto

Ovdje postoji važno razdvajanje.

Ako korisnik isključi automatsko produljenje pretplate, to obično ne znači da će pristup odmah prestati.

Trenutni plaćeni period može nadalje vrijediti.

Zbog toga, BillingMeld mora zadržati informacije da je daljnje produljenje isključeno, ali i razumjeti datum završetka već plaćenog razdoblja.

Samo nakon isteka tog razdoblja, pristup prestaje biti aktivan, ako nije došlo do novih potvrđenih produljenja.

Ovo je jedan od razloga zašto jednostavna logika „pretplata = istina“ nije dovoljno za normalni rad plaćanja.

Stanje pretplate uvijek je povezano s vremenom i događajima u njenom životnom ciklusu.

Produljenje — također zasebna provjera

Pretplata se ne završava nakon prve uplate.

Server mora znati je li došlo do sljedećeg produljenja i je li sljedeći plaćeni period doista potvrđen od strane trgovine.

BillingMeld prati te promjene i ažurira stanje pretplate.

Ako je produljenje potvrđeno, pravo pristupa se nastavlja.

Ako se ne izvrši nadoplata ili trgovina više ne potvrđuje sljedeći period, sustav ne smije jednostavno produljivati pristup pretpostavkom.

Za korisnika, to znači da pristup vrijedi onoliko koliko je plaćena pretplata.

Za programere, to znači da ne moraju svaki put implementirati istu logiku produljenja u svakoj aplikaciji.

Kako izgleda tipičan scenarij

Korisnik pretplaćuje u mobilnoj aplikaciji.

Kliënt prima informacije o kupnji i šalje potrebne podatke BillingMeld-u. No, samo ta poruka još uvijek nije osnova za konačno potvrđivanje kupnje.

BillingMeld provjerava operaciju putem odgovarajuće trgovine.

Ako App Store ili Google Play potvrđuje kupnju i njezino stanje je u skladu s pravilima proizvoda, BillingMeld bilježi aktivno pravo.

Nakon toga, povezane usluge pružaju korisniku plaćene mogućnosti.

Nastavlja se stanje koje je neovisno o početnoj poruci klijenta.

Ukoliko se pretplata produljuje, BillingMeld uzima u obzir novi plaćeni period.

Ako korisnik isključuje automatsko produljenje, trenutni period i dalje ostaje aktivan do svojega isteka.

Ako dođe do povrata ili povlačenja operacije, stanje se ponovno mijenja.

U toj shemi, aplikacija ne čuva vlastitu „istinu“ o kupnji. Ona radi sa stanjem koje je potvrđeno i pohranjeno u BillingMeld-u.

Što se događa pri promjeni uređaja

Serverski model posebno je koristan kada korisnik mijenja telefon ili ponovno instalira aplikaciju.

Pravo na kupnju ne bi smjelo postojati samo zato što je konkretni primjerak aplikacije nekada zabilježio uspješnu transakciju.

Obrnuto, ponovno instaliranje aplikacije ne bi trebalo poništiti potvrđeno pravo korisnika.

Ako je stanje kupnje na serverskoj strani i povezano je s potvrđenom trgovinskom operacijom, novi uređaj može dobiti važeće stanje preko servera.

Još jedan razlog zašto ne treba isključivo oslanjati pravila pristupa na mobilnog klijenta.

Što to donosi programerima

Za tim koji razvija više mobilnih aplikacija ili posluje s iOS-om i Androidom istovremeno, sistem naplate vrlo brzo postaje zasebna infrastrukturna funkcija.

Potrebno je uzeti u obzir:

• različite formate podataka Apple i Google;

• potvrdu prve kupnje;

• produljenja pretplata;

• završetak plaćenog razdoblja;

• isključivanje automatskog produljenja;

• povrate;

• povlačenje operacija;

• ponovnu instalaciju aplikacije;

• promjenu uređaja;

• obnavljanje kupnji;

• promjene stanja koje je nastalo bez sudjelovanja klijenta.

BillingMeld prebacuje tu logiku u poseban sloj. Serveri proizvoda rade s njim po ugovoru i ne trebaju samostalno tumačiti sve specifičnosti svake trgovine.

To smanjuje količinu dupliciranog koda, a što je još važnije, smanjuje šanse da različite aplikacije iste tvrtke različito tumače isti scenarij plaćanja.

Glavno nije potvrda, već pravo

Najviše me u toj arhitekturi zainteresirao prijelaz s provjere pojedinačne kupnje na kontrolu aktualnog stanja.

Povijesni podaci o uplati nisu sami po sebi odgovor na ključna pitanje proizvoda:

ima li korisnik trenutno pravo na plaćenu funkcionalnost?

U operaciji može biti uspješna početna kupnja, ali završeni period.

U pretplati može biti isključeno automatsko produljenje, ali već plaćeni rok i dalje vrijedi.

Može postojati potvrđeno produljenje.

Može biti izvršen povrat.

Trgovina može povući operaciju.

Zato je glavni objekt ne potvrda i prvi odgovor klijenta, već trenutno pravo korisnika, izvedeno iz potvrđenog stanja kupnje.

To upravo stanje BillingMeld s druge strane prenosi ostalim servisima.

BillingMeld kao granica između trgovina i proizvoda

Na temelju toga, javlja se vrlo jasna arhitektonska granica.

S jedne strane su App Store i Google Play sa svojom formom, događajima, pravilima i životnim ciklusima kupnje.

S druge, aplikacije i interne servise, kojima je najčešće potreban znatno jednostavniji odgovor: našta korisnik trenutno ima pravo?

Između njih nalazi se BillingMeld.

On prima podatke trgovine, provjerava ih, usklađuje s vlastitim modelom i pruža ostatku infrastrukture već normalizirani rezultat.

Zahvaljujući tome, produkti ne moraju poznavati sve unutarnje karakteristike svake plaćajne platforme.

Zašto je to važno za korisnika

Za korisnika, ispravna arhitektura naplate u idealnom slučaju ostaje praktički neprimjetna.

Ako je kupnja potvrđena i plaćeni period je aktivan, pristup treba funkcionirati.

Ako korisnik isključio automatsko produljenje, već plaćeni period ne smije prijevremeno nestati.

Ako je došlo do novog potvrđenog produljenja, pristup treba nastaviti.

Ako je trgovina potvrdila povrat ili povlačenje, sustav mora ispravno odraziti promjenu prava.

Pri promjeni uređaja ili ponovnoj instalaciji, korisniku ne bi smjelo biti potrebno ručno dokazivati svakom dijelu infrastrukture da kupnja doista postoji.

Ukupno, pravilo je dovoljno jednostavno:

Korisnik javlja o kupnji, trgovina je vanjski izvor njenog stanja, BillingMeld provjerava i normalizira to stanje, a ostali servisi donose odluke temeljem potvrđenih podataka BillingMeld-a.

Zato je BillingMeld ne samo još jedan modul plaćanja.

To je serverski sloj povjerenja između mobilne aplikacije, trgovina Apple i Google te proizvoda kojima je važno precizno znati koja plaćena prava korisnik trenutno ima.

Više o projektu: billingmeld.de.