BillingMeld: de ce serverul trebuie să verifice achiziția, nu aplicația

Cumpărarea în interiorul unei aplicații mobile pare de cele mai multe ori simplă pentru utilizator. Apasă butonul, confirmă plata, obține acces la funcție sau abonament — și așteaptă ca totul să funcționeze automat în continuare.

Pentru dezvoltator, în spatele acestui buton începe un proces mult mai complicat. Este nevoie să confirme însăși achiziția, să țină cont de reînnoiri, sfârșitul abonamentului,Returnări, recenzii ale operațiilor, schimbarea dispozitivului și diferențele între magazinele Apple și Google.

Principala problemă apare când serverul începe să consideri aplicația client ca sursă de adevăr.

Dacă aplicația spune: „Achiziția a fost realizată”, serverul permite accesul și continuă să se bazeze pe acea stare unică primită. Dar ciclul de viață al achiziției nu se încheie aici.

Abonamentul poate fi reînnoit, reînnoirea automată poate fi dezactivată, plata poate fi returnată, iar operațiunea poate fi retrasă de magazin.

De aceea, în BillingMeld, achiziția este confirmată nu de aplicație, ci de server.

Clientul informează, dar nu decide

În arhitectura BillingMeld, aplicația mobilă nu reprezintă sursa principală de informații despre achiziție.

Clientul poate transmite date despre operațiune, dar acestea sunt doar un fundament pentru verificare. Decizia finală o ia componenta server a BillingMeld, care validează informația prin infrastructura Apple sau Google.

Aceasta este o diferență fundamentală.

Aplicația de pe telefon poate lucra cu o stare veche, să nu primească în timp real modificările noi sau să transmită date care nu mai corespund statusului actual al achiziției.

De asemenea, clientul nu trebuie să aibă posibilitatea de a decide singur dacă utilizatorul are dreptul la acces plătit.

BillingMeld verifică, de exemplu:

• există chiar această achiziție;

• se refere la aplicația și produsul corect;

• perioada plătită este valabilă acum;

• s-a făcut o reînnoire;

• reînnoirea automată este dezactivată;

• s-a efectuat o rambursare;

• operațiunea nu a fost retrasă;

• perioada plătită nu s-a încheiat încă.

Astfel, mesajul clientului nu mai reprezintă dovada achiziției, ci un motiv de a verifica starea reală a acesteia.

Sursa unică de adevăr pentru servere

Serviciile conectate nu trebuie să implementeze singure întregul set de integrări simultan cu Apple și Google.

Ele contactează BillingMeld și primesc o stare normalizată a achiziției.

De exemplu: accesul este activ, perioada plătită s-a încheiat, o reînnoire a fost confirmată, reînnoirea automată a fost dezactivată sau achiziția a fost retrasă.

Acest lucru permite o delimitare clară a responsabilităților.

Apple și Google sunt sursele pentru starea operațiunii magazinului în sine. BillingMeld verifică aceste date, le convertește într-un model comun și le păstrează actualizate. Iar produsul final decide asupra accesului bazându-se pe statutul BillingMeld.

Pentru serverele produselor, acesta înseamnă un contract unificat în loc de mai multe integrări independente.

Nu mai este nevoie să implementezi pe fiecare serviciu reguli specifice App Store, Google Play, și apoi să încerci să uniformizezi diferitele formate, evenimente și statuse.

De ce nu trebuie să ai încredere total în client

Aplicația client rulează pe dispozitivul utilizatorului.

Poate fi închisă, repornită, restaurată din backup, actualizată mai târziu sau rulată pe alt dispozitiv. Poate funcționa pentru un timp cu o stare veche sau să nu primească evenimentul care a avut loc după achiziția inițială.

Chiar și fără intervenția utilizatorului, aceasta face ca sursa informațiilor finale despre abonament să fie clientul slab.

De exemplu, utilizatorul a realizat și obținut acces pe bază de abonament. Ulterior, achiziția a fost retrasă sau magazinul a revocat operațiunea.

Dacă serverul știe doar despre mesajul inițial de la client, va considera în continuare achiziția activă.

În alt scenariu, utilizatorul poate dezactiva reînnoirea automată. În acest caz, perioada deja plătită trebuie să rămână activă până la sfârșitul ei, chiar dacă reînnoirea nu s-a efectuat automat.

Dacă sistemul operează doar cu un status simplu: „abonament existent / nu există”, va putea închide accesul prea devreme sau, din contră, să lase accesul după ce dreptul a expirat.

BillingMeld este construit pe o logică diferită: clientul nu confirmă drepturile proprii. El transmite evenimentul, iar serverul stabilește starea efectivă a achiziției.

Achiziția nu e un eveniment singular

Unul dintre cele mai mari greșeli în arhitectura de billing este să consideri achiziția ca un singur eveniment.

De fapt, aceasta are un ciclu de viață.

Inițial, apare o operațiune. Apoi, ea este confirmată de magazin. Pentru abonament se începe perioada plătită. Ulterior, poate avea loc o reînnoire.

Utilizatorul poate dezactiva reînnoirea automată, dar poate continua să beneficieze de abonament până la sfârșitul perioadei plătite.

Plata poate eșua la următoarea reînnoire.

Se poate realiza o rambursare.

În unele cazuri, achiziția poate fi retrasă.

De aceea, nu ajunge doar să știi că „aceasta achiziție a existat cândva”.

Serverul trebuie să știe ce se întâmplă acum cu acesta.

Retragerea achiziției nu trece neobservată

Mai ales când vine vorba de rambursări și revocări, această nevoie devine clară.

Achiziția inițială putea fi perfect validă. Utilizatorul a plătit și a primit acces.

Dar mai târziu, starea operațiunii s-a schimbat.

Atunci când BillingMeld primește informații despre această schimbare, actualizează starea achiziției și, dacă e nevoie, verifică din nou datele prin magazin.

Ulterior, serviciul conectat lucrează deja cu noul statut.

Așadar, aplicația nu mai continuă să aibă o „adevăr” proprie despre achiziție. Ea lucrează cu starea confirmată și păstrată de BillingMeld.

Anularea abonamentului și expirarea accesului nu sunt același lucru

Aici există o diferență importantă.

Dacă utilizatorul a dezactivat reînnoirea automată, asta nu înseamnă neapărat că accesul trebuie să fie închis imediat.

Perioada plătită curentă poate continua să fie activă.

În acest caz, BillingMeld trebuie să păstreze informația că reînnoirea este dezactivată, dar în același timp să înțeleagă data sfârșitului perioadei plătite.

Și doar după această dată, dacă nu a fost realizată o reînnoire confirmată, accesul devine inactiv.

Aceasta exemplifică de ce valoarea booleană subscription = true nu e suficientă pentru un billing normal.

Starea abonamentului este întotdeauna legată de timp și de evenimentele ciclului de viață.

Reînnoirea este tot o verificare separată

Abonamentul nu se termină la prima plata.

Serverul trebuie să detecteze dacă a avut loc următoarea reînnoire și dacă perioada plătită următoare a fost confirmată de magazin.

BillingMeld monitorizează aceste schimbări și actualizează starea abonamentului.

Dacă reînnoirea este confirmată, dreptul la acces continuă.

Dacă plata pentru reînnoire eșuează sau magazinul nu mai confirmă perioada următoare, sistemul nu trebuie să prelungească accesul pe baza unei presupuneri.

Din punctul de vedere al utilizatorului, acest lucru pare natural: accesul există atât timp cât abonamentul plătit este activ.

Din perspectiva dezvoltatorilor, înseamnă că nu mai e nevoie să implementeze logica de reînnoire în fiecare aplicație în parte.

Cum arată un scenariu obișnuit

Utilizatorul face un abonament în aplicația mobilă.

Clientul primește informațiile despre achiziție și transmite datele necesare către BillingMeld. Însă, acest mesaj în sine încă nu înseamnă că achiziția este confirmată definitiv.

BillingMeld verifică operațiunea prin magazinul corespunzător.

Dacă App Store sau Google Play confirmă achiziția și starea ei respectă regulile produsului, BillingMeld înregistrează dreptul activ.

Ulterior, serviciul conectat oferă utilizatorului funcționalitățile plătite.

Starea continuă să fie actualizată independent de mesajul inițial trimis de client.

Dacă abonamentul se reînnoiește, BillingMeld consideră noua perioadă plătită.

Dacă utilizatorul dezactivează reînnoirea automată, perioada curentă continuă să fie valabilă până la sfârșitul ei.

Dacă are loc o rambursare sau o revocare, starea se schimbă din nou.

În acest scenariu, aplicația nu păstrează o „adevăr” proprie despre achiziție, ci lucrează cu starea confirmată și păstrată de BillingMeld.

Ce se întâmplă când se schimbă dispozitivul

Modelul serverless devine deosebit de util când utilizatorul schimbă telefonul sau reinstalează aplicația.

Dreptul achiziției nu trebuie să existe doar pentru că o anumită copie a aplicației a mai avut o tranzacție de succes.

Și invers, reinstalarea aplicației nu trebuie să distrugă dreptul confirmat al utilizatorului.

Dacă starea achiziției este păstrată pe server și legată de o operațiune confirmată în magazin, dispozitivul nou poate obține această stare actualizată de pe server.

Este încă un motiv pentru a nu păstra logica accesului exclusiv în clientul mobil.

Ce aduce aceasta pentru dezvoltatori

Pentru echipa care lansează mai multe aplicații mobile sau lucrează simultan cu iOS și Android, billingul devine rapid o problemă infrastructurală separată.

Trebuie să țină cont de:

• rezultatele diferite ale formatelor Apple și Google;

• confirmarea achiziției inițiale;

• reînnoirile abonamentului;

• sfârșitul perioadei plătite;

• dezactivarea reînnoirii automate;

• rambursările;

• revocările operațiunilor;

• reinstalarea aplicației;

• schimbarea dispozitivului;

• recuperarea achizițiilor;

• modificări de stare fără implicarea clientului.

BillingMeld externalizează această logică într-un strat specializat.

Serverele produselor lucrează cu acesta pe un contract unificat și nu trebuie să interpreteze în mod independent toate particularitățile fiecărui magazin.

Aceasta reduce cantitatea de cod duplicat și, ceea ce este și mai important, scade riscul ca aplicațiile diferite ale aceleiași companii să înțeleagă în mod diferit același scenariu de plată.

Principal nu mai este verificarea, ci dreptul actual

M-a interesat în arhitectura aceasta trecerea de la verificarea unei achiziții individuale la controlul stării actuale.

Factul că plata a fost efectuată nu răspunde în sine la întrebarea principală a produsului:

Are utilizatorul dreptul actual de a folosi funcționalitatea plătită?

Operațiunea poate avea o achiziție inițială reușită, dar perioada să fi expirat.

Abonamentul poate avea reînnoirea dezactivată, dar perioada plătită să fie încă activă.

Poate exista o reînnoire confirmată.

Poate fi realizată o rambursare.

Magazinul poate revoca operațiunea.

De aceea, nu cel mai important este chitanța sau răspunsul inițial al clientului, ci dreptul actual al utilizatorului, calculat pe baza stării confirmate a achiziției.

Aceasta este starea pe care BillingMeld o transmite celorlalte servicii.

BillingMeld ca graniță între magazine și produse

Ca urmare, apare o delimitare arhitecturală clară.

Pe de o parte, sunt App Store și Google Play, cu formatele, evenimentele, regulile și ciclurile lor de viață pentru achiziții.

Pe de altă parte, angajamentele aplicațiilor și serviciilor interne, care de cele mai multe ori au nevoie de un răspuns mult mai simplu: ce drepturi are în prezent utilizatorul.

Între ele se află BillingMeld.

El primește datele magazinului, le verifică, le convertește într-un model proprie și le furnizează celorlalte infrastructuri rezultatul normalizat.

Datorită acestui sistem, produsele nu trebuie să cunoască toate particularitățile fiecărei platforme de plată.

De ce este important pentru utilizator

Pentru utilizator, o arhitectură de billing corectă ar trebui în mod ideal să fie aproape invizibilă.

Dacă achiziția este confirmată și perioada plătită este activă, accesul trebuie să funcționeze.

Dacă utilizatorul a dezactivat reînnoirea automată, perioada plătită nu trebuie să dispară înainte de timp.

Dacă are loc o reînnoire nouă, accesul trebuie să continue.

Dacă magazinul confirmă rambursarea sau revocarea, sistemul trebuie să reflecte corect schimbarea dreptului.

La schimbarea dispozitivului sau la reinstalarea aplicației, utilizatorul nu trebuie să fie nevoit să demonstreze manual fiecărei părți a infrastructurii că achiziția verificată chiar există.

Regula rezultată este destul de simplă:

clientul informează despre achiziție, magazinul rămâne sursa externă a stării sale, BillingMeld verifică și normalizează această stare, iar celelalte servicii decid în baza datelor confirmate de BillingMeld.

De aceea, BillingMeld nu este doar un modul de plată în plus.

Este un strat de încredere server-side între aplicația mobilă, magazinele Apple și Google și serviciile de produs, care trebuie să înțeleagă precis ce drepturi plătite aparțin utilizatorului în momentul actual.

Detalii despre proiect: billingmeld.de.