BillingMeld: prečo by mal server overiť nákup, nie aplikácia

Vnútorný nákup v mobilnej aplikácii sa zvyčajne javí ako jednoduchý pre používateľa. Stlačí tlačidlo, potvrdí platbu, získa prístup k funkcii alebo odberu — a očakáva, že všetko ďalej bude fungovať automaticky.

Pre vývojára začína za týmto tlačidlom oveľa zložitejšie procesy. Je potrebné potvrdiť samotný nákup, sledovať predĺženia, ukončenie odberu, vrátenia, zmeny statusu operácií, zmenu zariadenia a rozdiely medzi obchodmi Apple a Google.

Hlavný problém vzniká, keď server začína považovať klientskú aplikáciu za hlavný zdroj pravdy.

Ak aplikácia oznámi: „Nákup bol uskutočnený“, server odomkne prístup a naďalej sa opiera o jedenkrát získaný stav. No životný cyklus nákupu tým neskončí.

Odber môže byť predĺžený, auto-predĺženie môže byť vypnuté, platba môže byť vrátená, a samotná operácia — odvolaná obchodom.

Preto BillingMeld potvrdenie nákupu nevidí v aplikácii, ale na serveri.

Klient hlási, ale nerozhoduje

V architektúre BillingMeld nie je mobilná aplikácia hlavným zdrojom informácií o nákupe.

Klient môže odovzdať údaje o vykonanej operácii, ale je to len základ pre kontrolu. Konečné rozhodnutie prichádza zo serverovej časti BillingMeld, ktorá overuje informácie cez infraštruktúru Apple alebo Google.

Ide o zásadný rozdiel.

Na telefóne môže pracovať so starým stavom, nezískať načas najnovšiu zmenu alebo odovzdať údaje, ktoré už neodpovedajú aktuálnemu stavu nákupu.

Navyše, klient by nemal mať možnosť sám rozhodovať, či má používateľ nárok na platený prístup.

BillingMeld overuje napríklad:

• či takýto nákup skutočne existuje;

• či patrí k správnemu aplikačnému balíku a produktu;

• či je aktuálne aktívny platený čas;

• či nastalo predĺženie;

• či je vypnuté ďalšie auto-predĺženie;

• či bol vykonaný vrátenie;

• či nebola operácia odvolaná;

• či ešte nevypršal platený čas.

Takže oznámenie klienta už nie je dôkazom nákupu, ale podnetom na kontrolu jeho aktuálneho stavu.

Jediný zdroj pravdy pre servery

Pripojené služby nemusia samostatne implementovať celý rad integrácií s Apple a Google naraz.

Obracajú sa na BillingMeld a dostávajú už normalizovaný stav nákupu.

Například: je aktivovaný prístup, skončil platený čas, bolo potvrdené predĺženie, auto-predĺženie je vypnuté alebo nákup odvolaný.

To umožňuje jasne rozlíšiť zodpovednosti.

Apple a Google sú zdrojmi stavu samotnej obchodnej operácie. BillingMeld tieto údaje overí, prevedie do jednotného modelu a uchová aktuálny stav. A konečný produkt rozhoduje o prístupe na základe stavu BillingMeld.

Pre servery produktov to znamená jednotný kontrakt namiesto niekoľkých nezávislých integrácií.

Nie je potrebné v každom servise osobitne implementovať pravidlá App Store, Google Play a snažiť sa zlúčiť rôzne formáty, udalosti a stavy do jednej logiky.

Prečo nemôžete úplne dôverovať klientovi

Klientská aplikácia beží na zariadení používateľa.

Je možné ho vypnúť, reštartovať, obnoviť z zálohy, neskôr aktualizovať alebo spustiť na inom zariadení. Môže niekoľko chvíľ pracovať s neaktuálnymi údajmi alebo vôbec nezískať udalosť, ktorá nastala po počiatočnom nákupe.

Nielen bez zásahu používateľa sa to stáva zlým zdrojom konečného stavu odberu.

Napríklad používateľ si objedná odber a získa prístup. Neskôr je nákup vrátený alebo operácia odvolaná obchodom.

Ak server vie iba o počiatočnej správe od klienta, bude považovať nákup za platný.

V inom prípade môže používateľ vypnúť auto-predĺženie. Platný čas musí stále zostať aktívny do dátumu ukončenia.

Ak systém pracuje iba s primitívnym stavom „odber je / odber nie je“, ľahko začne zatvárať prístup príliš skoro alebo ho ponechá, aj keď právo na používanie už skončilo.

BillingMeld je založený na inom prístupe: klient nepotvrdzuje svoje práva sám. Oznámi udalosť, a server určí skutočný stav nákupu.

Nákup nie je jedna udalosť

Jedna z hlavných chýb v architektúre platenia je považovať nákup za jedinú udalosť.

V skutočnosti má životný cyklus.

Na začiatku je operácia. Potom je potvrdená obchodom. Pre odber začína platený čas. Neskôr môže nasledovať ďalšie predĺženie.

Používateľ si môže vypnúť auto-predĺženie, ale môže naďalej využívať odber do ukončenia aktuálneho plateného obdobia.

Platba môže zlyhať pri ďalšom predĺžení.

Môže byť vykonané vrátenie.

V niektorých prípadoch môže byť nákup odvolaný.

Preto nestačí len fakt „tento nákup kedysi existoval“.

Dôležité je, čo sa s ním deje práve teraz.

Vrátenie nákupu neostáva bez povšimnutia

Obzvlášť dobre je vidieť potrebu serverovej architektúry pri vráteniach alebo odvolaniach operácií.

Počiatočný nákup mohol byť úplne správny. Používateľ skutočne zaplatil za produkt a získal prístup.

Avšak neskôr sa stav operácie zmenil.

Ak BillingMeld dostane informácie o zmene, aktualizuje vlastný stav nákupu a podľa potreby overí údaje cez obchod.

Po tomto pripojený servis pracuje s novým stavom.

Takto aplikácia nehľadá neustále definitívnu verziu toho, že klient raz pred niekoľkými týždňami alebo mesiacmi oznámil úspešný nákup.

Ak obchod prestane považovať právo za platné, BillingMeld odrazí túto zmenu vo svojom stave.

Zrušenie odberu a ukončenie prístupu nie sú to isté

Tu je dôležité rozlíšenie.

Ak používateľ vypne auto-predĺženie odberu, to zvyčajne neznamená, že prístup sa má okamžite uzavrieť.

Aktuálny platený čas môže naďalej platiť.

V takom prípade BillingMeld musí uložiť informáciu, že ďalšie predĺženie je vypnuté, ale zároveň rozumie dátumu ukončenia aktuálneho plateného obdobia.

Až po jeho skončení sa prístup považuje za neaktívny, ak nedošlo k novému potvrdenému predĺženiu.

Toto je jeden z dôvodov, prečo nestačí jednoduché booleovské pole subscription = true na správu odberu.

Stav odberu je vždy časovo závislý a viaže sa na životný cyklus udalostí.

Predĺženie je tiež samostatná kontrola

Odber nekončí pri prvej platbe.

Server musí rozpoznať, či došlo k ďalšiemu predĺženiu a či je nasledovné platené obdobie naozaj potvrdené obchodom.

BillingMeld tieto zmeny sleduje a aktualizuje stav odberu.

Ak je predĺženie potvrdené, právo na prístup pokračuje.

Ak sa neuskutoční žiadne ďalšie strhnutie alebo obchod už nepotvrdzuje ďalšie obdobie, systém nesmie len tak predĺžiť prístup na základe svojho odhadu.

Pre používateľa to vyzerá prirodzene: prístup platí tak dlho, ako platí odber.

Pre vývojárov to znamená, že nemusia kópiť rovnakú logiku predlžovania v každej aplikácii.

Ako vyzerá bežný scenár

Používateľ si objedná odber v mobilnej aplikácii.

Klient získa informácie o nákupe a odovzdá potrebné údaje BillingMeld. No toto oznámenie ešte neznačí, že nákup je definitivne potvrdený.

BillingMeld overí operáciu cez príslušný obchod.

Ak App Store alebo Google Play potvrdí nákup a jeho stav zodpovedá pravidlám produktu, BillingMeld zaznamená aktívne právo.

Po tom pripojený servis poskytne používateľovi zakúpené funkcie.

Stav sa ďalej spravuje nezávisle od pôvodného oznámenia klienta.

Ak sa odber predlžuje, BillingMeld zváži nový platený čas.

Ak používateľ vypne auto-predĺženie, aktuálny čas naďalej platí do ukončenia.

Ak dôjde k vráteniu alebo odvolaniu operácie, stav sa znova zmení.

V tejto schéme aplikácia neuchováva vlastnú „pravdu“ o nákupe. Pracuje so stavom potvrdeným a uloženým BillingMeldom.

Čo sa deje pri zmene zariadenia

Táto serverová architektúra je obzvlášť výhodná, keď používateľ mení telefón alebo inštaluje aplikáciu znova.

Právo na nákup by nemalo závisieť iba od toho, že konkrétny inštancia aplikácie kedysi zaznamenala úspešnú transakciu.

Naopak, preinštalovanie aplikácie by nemalo zrušiť potvrdené právo používateľa.

Ak je stav nákupu uchovávaný na serveri a je viazaný na potvrdenú obchodnú operáciu, nové zariadenie môže získať aktuálny stav cez server.

Toto je ďalší dôvod, prečo neukladať logiku prístupu striktne vo vnútri mobilného klienta.

Čo to prináša vývojárom

Pre tímy, ktoré vyvíjajú viacero mobilných aplikácií alebo fungujú súčasne na iOS a Android, sa platenie rýchlo stáva samostatnou infraštruktúrnou úlohou.

Je potrebné zohľadniť:

• rôzne formáty dát Apple a Google;

• potvrdenie počiatočného nákupu;

• predĺženia odberov;

• ukončenie plateného obdobia;

• vypnutie auto-predĺženia;

• vrátenia;

• odvolanie operácií;

• opakovaná inštalácia aplikácie;

• Zmena zariadenia;

• obnova nákupov;

• zmeny stavu, ku ktorým došlo bez zásahu klienta.

BillingMeld prenáša túto logiku do samostatného špecializovaného vrstvy.

Servery produktov s ním pracujú podľa jednotného kontraktu a nemusia samostatne interpretovať všetky špecifiká jednotlivých obchodov.

Toto znižuje duplicitu kódu a, čo je ešte dôležitejšie, znižuje riziko, že rôzne aplikácie jednej firmy budú chápať rovnaký platiebny scenár odlišne.

Hlavným nie je kontrola, ale aktuálne právo

Najviac ma v tejto architektúre zaujalo prechod od kontroly jednotlivého nákupu k správaniu aktuálneho stavu.

Historické platby samé osebe ešte nezodpovedajú hlavnej otázke produktu:

má používateľ právo k platenej funkcii práve teraz?

Niekedy je počiatočný nákup úspešný, ale platnosť skončila.

Odber môže byť vypnutý, ale už zaplatený čas ešte pokračuje.

Existuje potvrdené predĺženie.

V rámci nákupu môže byť vykonaný vrátenie.

Obchod môže operáciu odvolať.

Preto hlavnou jednotkou nie je doklad ani počiatočná odpoveď klienta, ale aktuálne právo používateľa založené na potvrdenom stave nákupu.

Presne túto informáciu BillingMeld odovzdáva ostatným službám.

BillingMeld ako hranica medzi obchodmi a produktmi

Vďaka tomu vzniká veľmi jasná architektonická hranica.

S jednej strany sú App Store a Google Play so svojimi formátmi, udalosťami, pravidlami a životnými cyklami nákupov.

S druhej – aplikácie a interné služby, ktoré väčšinou potrebujú oveľa jednoduchšiu odpoveď: aké práva má používateľ práve teraz.

Medzi nimi je BillingMeld.

Prijíma obchodné údaje, overuje ich, prevádza do vlastného modelu a poskytuje ostatnej infraštruktúre už normalizovaný výsledok.

Vďaka tomu produkty nemusia poznať všetky interné špecifiká jednotlivých platobných platforiem.

Prečo je to dôležité pre používateľa

Pre používateľa by mala byť správna bilaterálna architektúra v ideálnom prípade úplne nebadateľná.

Ak je nákup potvrdený a platený čas platí, prístup má fungovať.

Ak používateľ vypne auto-predĺženie, zaplatený čas by nemal skončiť predčasne.

Ak dôjde k novému potvrdenému predĺženiu, prístup by mal pokračovať.

Ak obchod potvrdí vrátenie alebo odvolanie, systém by mal správne odraziť zmenu práva.

Pri zmene zariadenia alebo opätovnej inštalácii aplikácie by používateľ nemal musieť ručne dokazovať, že nákup skutočne existuje.

Výsledná pravidlo znie jednoducho:

klient hlási nákup, obchod je vonkajším zdrojom jeho stavu, BillingMeld ho overí a normalizuje, a ostatné služby rozhodujú na základe potvrdených dát od BillingMeld.

Preto BillingMeld nie je len ďalším modulom platby.

Je to serverová vrstva dôvery medzi mobilnou aplikáciou, obchodmi Apple a Google a produktmi, ktoré musia presne vedieť, aké platené práva používateľ má práve teraz.

Viac informácií o projekte na: billingmeld.de.