BillingMeld: miért kell a szervernek ellenőriznie a vásárlást, nem pedig az alkalmazásnak

A mobilalkalmazáson belüli vásárlás általában csak a felhasználó számára tűnik egyszerűnek. Beckham nyomogatja a gombot, megerősíti a fizetést, hozzáférést kap a funkcióhoz vagy az előfizetéshez – és elvárja, hogy ezután minden automatikusan fog menni.

FEJLESZTŐ szempontból azonban a gomb mögött sokkal bonyolultabb folyamat áll. Meg kell erősíteni maga a vásárlást, figyelni az megújításokat, az előfizetés végdátumát, visszatérítéseket, műveleti visszajelzéseket, az eszközváltást, valamint az Apple és Google áruházai közötti különbségeket.

Fő problémát jelent, amikor a szerver azt kezdi hinni, hogy a kliensalkalmazás az egyetlen igaz forrás.

Ha az alkalmazás azt mondja: „Vásárlás megtörtént”, a szerver megnyitja a hozzáférést, és továbbra is a korábban kapott állapotra hagyatkozik. De a vásárlás életciklusa nem ér véget itt.

A vásárlás megújítható, az automatikus megújítás kikapcsolható, a fizetés visszatéríthető, vagy az operációt a bolt visszavonhatja.

Ezért a BillingMeld-ben a vásárlást nem az alkalmazás, hanem a szerver erősíti meg.

A kliens jelenti, de nem dönt

A BillingMeld architektúrájában a mobilalkalmazás nem a fő információforrás a vásárlásról.

A kliens átadhatja a vásárlás pontos adatait, de ez csak a hitelesítés alapja. A végső döntést a BillingMeld szerver oldala hozza meg, amely az információt az Apple vagy Google infrastruktúráján keresztül ellenőrzi.

Ez alapvető különbség.

A telefonos alkalmazás régi állapotokkal dolgozhat, nem kaphatja meg időben a legújabb változásokat, vagy olyan adatokat adhat át, amelyek már nem felelnek meg a valós vásárlási helyzetnek.

Ezen kívül a kliens nem jogosult saját döntést hozni arról, hogy a felhasználónak fizetős hozzáférést szabad-e biztosítani.

A BillingMeld például ellenőrzi:

• létezik-e egyáltalán ilyen vásárlás;

• tartozik-e a megfelelő alkalmazáshoz és termékhez;

• aktuális-e a fizetett időszak;
• történt-e megújítás;
• kikapcsolták-e az automatikus megújítást;

• volt-e visszatérítés;
• volt-e a művelet visszavonva;
• lejárt-e a fizetett időszak.

Ezért a kliens üzenete nem a vásárlás bizonyítéka, hanem arra szolgál, hogy ellenőrizze a valós állapotát.

Egyetlen valódi forrás szerverek számára

Csatlakoztatott szolgáltatásoknak nem kell egyszerre több integrációt megvalósítaniuk az Apple- és Google-platformokkal.

A BillingMeldhez fordulnak, és azonnal megkapják a vásárlás normálizált állapotát.

Például: aktív a hozzáférés, lejárt a fizetett időszak, megerősítették a megújítást, kikapcsolták az automatikus megújítást, vagy a vásárlást visszavonták.

Ez lehetővé teszi a felelősség egyértelmű megosztását.

Az Apple és a Google az üzlet műveletének állapotát szolgáltató források. A BillingMeld ezeket az adatokat ellenőrzi, egységes modellhez igazítja, és az aktuális állapotot tárolja. A végső hozzáférési döntést a BillingMeld státusza alapján hozzák meg.

Ez az egységes szerződés a termékhez kapcsolódó szerverek számára, nem szükséges külön-külön értelmezni a különböző platformok sajátosságait.

Nem kell minden szolgáltatásban külön-külön implementálni az App Store, vagy Google Play szabályokat, majd próbálni összhangba hozni a különböző formátumokat, eseményeket és státuszokat.

Miért nem lehet teljes mértékben bízni a kliensben

A kliens alkalmazás a felhasználó eszközén fut.

Lezárhatják, újraindíthatják, visszaállíthatják biztonsági mentésből, később frissíthetik, vagy egy másik eszközön is elindíthatják. Időnként régi adatokkal dolgozik, vagy nem kapja meg azokat az eseményeket, amik a vásárlás eredeti pillanatában történtek.

Még a felhasználói beavatkozás nélkül is ezen jogforrások megbízhatatlanok lehetnek a végső állapot meghatározásában.

Például a felhasználó megvásárol egy előfizetést, hozzáférést kap, majd később a vásárlás visszatérítése vagy az operáció visszavonása történik.

Ha a szerver csak az első kliens üzenetére hagyatkozik, akkor a vásárlást továbbra is aktívnak fogja tartani.

Sőt, a felhasználó kikapcsolhatja az automatikus megújítást, de a már fizetett időszak még mindig tart, amíg le nem jár.

Ha a rendszer csak primitív állapotokat ismer – például „előfizetés van / nincs” –, könnyen zárhatja túl korán a hozzáférést, vagy épp túl későn, amikor már az előfizetés jogai már megszűntek.

A BillingMeld más logikára épül: a kliens nem erősíti meg saját jogait. Az eseményeket jelzi, de a szerver a vásárlás aktuális állapotát határozza meg.

A vásárlás nem egy esemény

Az egyik fő hiba a fizetési architektúrában, ha a vásárlást egyetlen eseményként kezeljük.

Valójában az életciklusa van.

Először létezik egy művelet. Aztán jóváhagyja azt az áruház. Megkezdődik a fizetett időszak egy előfizetés esetében. Aztán lehetőség van újabb megújításra.

A felhasználó kikapcsolhatja az automatikus megújítást, de még így is használhatja az előfizetést a megfizetett időszak végéig.

A következő megújítás nem sikerülhet, vagy az üzlet visszavonhatja a műveletet.

Visszatérítés is kérhető lehet.

Egyes esetekben a vásárlás visszavonható.

Ezért az „egyszer volt, hol nem volt” nem elegendő a szervernek.

Fontos tudni, mi történik most ezzel a vásárlással.

A visszavont vásárlás nem marad észrevétlen

Ez különösen jól látható a visszatérítéseknél és a visszavont műveleteknél.

Az eredeti vásárlás lehet, hogy tökéletesen helyes volt. A felhasználó valóban fizetett, és hozzáférést kapott.

De később az állapot megváltozik.

Ha a BillingMeld információt kap a változásról, frissíti saját vásárlási állapotát, és szükség szerint ellenőrzi az adatokat az áruházzal.

Ezután a csatlakoztatott szolgáltatás már az új státusszal dolgozik.

Így a kliens nem tud az örökké tartó hitben élni arról, hogy a vásárlás sikeresen történt valamikor hetekkel vagy hónapokkal ezelőtt.

Ha az üzlet már nem tartja fenn az adott jogot, a BillingMeld ezt tükrözi az állapotában.

A felhasználó kilépése vagy hozzáférésének vége nem ugyanaz

Itt fontos különbség van.

Ha a felhasználó kikapcsolja az automatikus megújítást, ez általában nem jelenti azt, hogy a hozzáférés azonnal megszűnik.

A fizetett időszak továbbra is aktív lehet.

Ilyenkor a BillingMeld megőrzi, hogy a további megújítás kikapcsolásra került, de ugyanakkor figyeli a már fizetett időszak vég dátumát.

Csak akkor szűnik meg a hozzáférés, ha az idő letelik, és új megerősített megújítás nem történt.

Ez az egyik oka annak, miért nem elég egy egyszerű „subscription = true” logika a normál fizetésekhez.

A jog mindig időhöz kötött és eseményekhez kapcsolódik az életciklusában.

A megújítás is külön ellenőrzést igényel

A vásárlás nem ér véget az első fizetéssel.

A szervernak értenie kell, történt-e újabb megújítás, és a következő fizetett időszak valóban megerősítette-e az üzlet.

A BillingMeld figyeli ezeket a változásokat, és frissíti az előfizetés állapotát.

Ha a megújítás megtörtént, a hozzáférés jogát folytatni kell.

Ha a következő fizetés nem sikerül vagy az üzlet nem erősíti meg a következő időszakot, a rendszer nem szabad automatikusan meghosszabbítania a hozzáférést saját becslés alapján.

Felhasználó szempontjából ez normálisnak tűnik: a hozzáférés addig él, ameddig a fizetett előfizetés aktív.

A fejlesztők számára ez azt jelenti, hogy ugyanazt a megújítási logikát nem kell minden alkalmazásban újra implementálni.

Hogyan néz ki egy szokásos forgatókönyv

A felhasználó előfizetést köt egy mobilalkalmazásban.

A kliens információt kap a vásárlásról, és megküldi a szükséges adatokat a BillingMeld-nek. De ez a kommunikáció még nem tekinthető végleges megerősítésnek.

A BillingMeld ellenőrzi a műveletet az adott áruházon keresztül.

Ha az App Store vagy Google Play megerősíti a vásárlást, és az állapota megfelel a termék szabályainak, a BillingMeld rögzíti az aktív jogot.

Ezt követően a csatlakoztatott szolgáltatás biztosítja a felhasználónak a megfizetett lehetőségeket.

Az állapot ezt követően már függetlenül él a kezdeti kliensüzenettől.

Ha az előfizetést meghosszabbítják, a BillingMeld figyelembe veszi az új fizetett időszakot.

Ha a felhasználó kikapcsolja az automatikus megújítást, a jelenlegi időszak a végetértekor még tart.

Ha visszatérítés vagy visszavonás történik, az állapot ismét változik.

Ebben a rendszerben az alkalmazás nem tárol közvetlen „igazságot” a vásárlásról. Egy olyan állapottal dolgozik, melyet a BillingMeld igazolt és tárol.

Mi történik az eszközváltás esetén

A szerver oldali modell különösen hasznos, amikor a felhasználó telefoncserét vagy újratelepítést végez.

A jog nem szűnik meg attól, hogy egy adott alkalmazáspéldány egyszer sikeresen feldolgozta a tranzakciót.

És fordítva: az újratelepítés nem szünteti meg a felhasználói megerősített jogot.

Ha a vásárlási állapot a szerver oldalon van, és kötődik az elfogadott áruházi művelethez, az új eszköz a szerveren keresztül eléri az aktuális állapotot.

Ez az egyik oka annak, hogy nem csak az alkalmazás kliensének döntését bízzuk meg a hozzáférés szabályozásában.

Mit jelent ez a fejlesztők számára

Azoknak a csapatoknak, amelyek több mobilalkalmazáson dolgoznak, vagy iOS és Android rendszeren egyaránt, a fizetési logika gyorsan infrstrukturális feladattá válik.

Figyelembe kell venni:

• Apple- és Google-formátumok közötti különbségeket;

• az első vásárlás megerősítését;

• az előfizetések megújítását;

• a fizetett időszak végét;

• az automatikus megújítás kikapcsolását;

• visszatérítéseket;

• egyes műveletek visszavonását;

• újratelepítést;

• eszközváltást;

• vásárlások helyreállítását;

• valós idejű állapotváltozásokat, amelyek kliens részvétele nélkül történnek.

A BillingMeld ezeket a logikákat különálló, szpecializált rétegbe szervezi.

A termék szerverei ezzel az egységes szerződéssel dolgoznak, nem kell minden áruház sajátosságait külön értelmezniük.

Ez csökkenti a duplikált kódok számát, és ami még fontosabb, csökkenti az esélyét annak, hogy különböző alkalmazások ugyanazon fizetési folyamatot eltérően értelmezzék.

A fő szempont nem a vásárlási bizonylat, hanem a jog aktuális volta

Az egyik legnagyobb változás, amit ez az architektúra hozott, a vásárlás ellenőrzéséről való átállás az aktuális állapot ellenőrzésére.

A fizetés története önmagában nem ad választ a legfontosabb kérdésre: jogosult-e még a felhasználó a fizetős funkciókra most?

Az operációnak lehet sikeres első vásárlása, de az már lejárt időszakot is jelenthet.

Előfizetés esetében kikapcsolhatják az automatikus megújítást, de még a már fizetett időszak alatt is érvényben lehet a jogosultság.

Létezhet megerősített megújítás.

Visszatérítés is kérhető.

Az üzlet visszavonhatja az operációt.

Ezért a fő objektum nem a blokk vagy az első válasz, hanem a felhasználó aktuális joga, a vásárlás igazolt állapotának alapján.

Ezt az állapotot továbbítja a BillingMeld a többi szolgáltatás felé.

A BillingMeld mint határ az áruházak és az alkalmazások között

Ez egy elég határozott architekturális határvonal kialakulását eredményezi.

Egyrészt az App Store és Google Play saját formátumaikkal, eseményeikkel, szabályaikkal és életciklusukkal.

Másrészt pedig az alkalmazások és belső szolgáltatások, amelyeknek leginkább egy sokkal egyszerűbb választ kell nyújtani: jelenleg milyen jogok vannak a felhasználónál.

Ez utóbbi szerepel a BillingMeld.

Ő fogadja a bolt adatait, ellenőrzi, normalizálja, és a többi infrastruktúra felé már egységes eredményt szolgáltat.

Ezáltal a termékek nem szükségszerűen ismerik meg minden belső részletet az egyes fizetési platformokról.

Miért fontos ez a felhasználónak

A felhasználónak ez a jól tervezett fizetési architektúra ideálisan láthatatlan kell, hogy legyen.

Ha a vásárlás igazolt, és a fizetett időszak aktív, a hozzáférésnek működnie kell.

Ha a felhasználó kikapcsolja az automatikus megújítást, akkor sem szabad az előre fizetett időszaknak idő előtt vége szakadnia.

Ha újabb sikeres megújítás történik, a hozzáférés folytatódik.

Ha a bolt visszaigazolja a visszatérítést vagy a visszavonást, a változást helyesen kell tükrözni a jogosultság szerint.

Eszközváltás vagy alkalmazás újratelepítése esetén nem kell minden infrastruktúra rétegbe manuálisan bebizonyítani, hogy a vásárlás valóban megtörtént.

Az alábbi egyszerű szabály érvényes:

A kliens jelzi a vásárlást, a bolt külső forrás, az aktuális állapotot a BillingMeld ellenőrzi és normalizálja, majd a többi szolgáltatás végső döntése már az ezt igazoló adatokon alapul.

Ezért a BillingMeld nem egyszerűen egy fizetőmodul, hanem egy szerver oldali bizalmi réteg a mobilalkalmazás, az Apple- és Google-boltok, valamint a termékek között, melyeknek pontosan tudniuk kell, hogy jelenleg milyen fizetős jogok illetik meg a felhasználót.

A projektről bővebben: billingmeld.de.