BillingMeld: proč by měla kontrolu provádět server, nikoliv aplikace

Nákup uvnitř mobilní aplikace se obvykle zdá být jednoduchý pouze pro uživatele. Klepne na tlačítko, potvrdí platbu, získá přístup ke službě nebo předplatnému — a očekává, že vše bude následně fungovat automaticky.

Pro vývojáře však za tímto tlačítkem následuje mnohem složitější proces. Je třeba potvrdit samotný nákup, brát v úvahu prodloužení, ukončení předplatného, vrácení, zpětnou vazbu na operace, změnu zařízení a rozdíly mezi obchody Apple a Google.

Hlavní problém nastává, když začne server považovat klientskou aplikaci za hlavní zdroj pravdy.

Pokud aplikace oznámí: „Nákup byla provedena“, server otevře přístup a dále se orientuje na jednu stanovenou informaci. Ale životní cyklus nákupu tím nekončí.

Předplatné může být prodlouženo, automatické prodloužení může být vypnuto, platba může být vrácena a operace sama může být stažena obchodem.

Proto BillingMeld potvrzuje nákup ne aplikace, ale server.

Klient oznamuje, ale nerozhoduje

V architektuře BillingMeld není mobilní aplikace hlavním zdrojem informace o nákupu.

Klient může předat data o provedené operaci, ale to je pouze základ pro kontrolu. Konečné rozhodnutí přijímá serverová část BillingMeld, která ověřuje informace přes infrastrukturu Apple nebo Google.

To je zásadní rozdíl.

Aplikace na telefonu může pracovat se starým stavem, nedostat čas na získání další změny nebo předat údaje, které už neodpovídají aktuálnímu stavu nákupu.

Kromě toho by klient neměl mít možnost sám rozhodnout, zda má uživateli být poskytnut placený přístup.

BillingMeld například ověřuje:

• zda takový nákup skutečně existuje;

• zda se vztahuje na požadovanou aplikaci a produkt;

• zda je právě nyní aktivní zaplacené období;

• zda došlo k dalšímu prodloužení;

• zda je automatické prodloužení vypnuto;

• zda byl proveden refund;

• zda operace nebyla stažena;

• zda zaplacené období nevypršelo.

Takže oznámení klienta již není důkazem o nákupu, ale důvodem k ověření jeho skutečného stavu.

Jednotný zdroj pravdy pro servery

Připojené služby nemusí samy implementovat kompletní sadu integrací s Apple i Google.

Obrací se na BillingMeld a obdrží již normalizovaný stav nákupu.

Například: přístup je aktivní, zaplacené období skončilo, další prodloužení je potvrzeno, automatické prodloužení je vypnuto nebo nákup byl stažen.

To umožňuje jasně rozdělit odpovědnost.

Apple a Google jsou zdroje stavu samotné operace v obchodě. BillingMeld tyto údaje ověřuje, převádí je do společného modelu a uchovává aktuální stav. A konečný produkt o přístupu rozhoduje na základě stavu BillingMeld.

Pro servery produktů to znamená jednotnou dohodu místo několika nezávislých integrací.

Není třeba v každé službě zvlášť nést pravidla App Store, Google Play, a zároveň se snažit sjednotit různé formáty, události a stavy do společné logiky.

Proč plně nedůvěřovat klientovi

Klientská aplikace běží na zařízení uživatele.

Je možné ji zavřít, restartovat, obnovit ze zálohy, později aktualizovat nebo spustit na jiném zařízení. Může nějakou dobu pracovat se starými údaji nebo vůbec nezískat události, ke kterým došlo po původním nákupu.

I bez zásahu uživatele tak činí klient špatným zdrojem konečného stavu předplatného.

Napríklad, uživatel provedl předplatné a získal přístup. Později byl nákup vrácen nebo obchod operaci stáhl.

Pokud server zná pouze počáteční zprávu od klienta, bude nadále považovat nákup za platný.

V jiné situaci uživatel může vypnout automatické prodloužení. I přesto by již zaplacené období mělo zůstat aktivní do jeho konce.

Pokud systém pracuje pouze s jednoduchým stavem „předplatné je / není“, snadno se stane, že přístup bude uzavřen příliš brzy nebo zbytečně dlouho po vypršení práva.

BillingMeld je postaven na jiné logice: klient nepotvrzuje svá práva. Oznámí událost, a server určuje skutečný stav nákupu.

Nákup — to není jediná událost

Jeden z hlavních omylů v architektuře fakturace je vnímání nákupu jako jediné události.

Ve skutečnosti má životní cyklus.

Nejprve vznikne operace. Potom je potvrzena obchodem. U předplatného začíná zaplacené období. Později může dojít k dalšímu prodloužení.

Uživatel může vypnout autoprodloužení, ale stále využívat předplatné až do konce již zaplaceného období.

Platba může při dalším prodloužení selhat.

Může být proveden refund.

V některých případech může být nákup stažen.

Proto nestačí jen fakt „tato koupě někdy existovala“.

Pro server je důležité pochopit, co je s ní právě teď.

Storno nákupu není přehlédnutelné

Toto je zvlášť patrné při vrácení a stažení operace.

Původní nákup mohl být zcela korektní. Uživatel skutečně zaplatil a získal přístup.

Nicméně stav operace se později změnil.

Pokud BillingMeld obdrží informace o změně, aktualizuje svůj stav a případně provede ověření přes obchod.

Poté již připojená služba pracuje se zcela aktuálním stavem.

Tím pádem aplikace již nedůvěřuje pouze faktu, že před několika týdny či měsíci klient hlásil úspěšný nákup.

Pokud obchod již nevidí dané právo jako platné, BillingMeld to odráží ve svém stavu.

Zrušení předplatného a ukončení přístupu — není totéž

Zde je důležité rozlišení.

Pokud uživatel vypne autoprodloužení, obvykle to neznamená, že přístup musí být ihned ukončen.

Aktuální zaplacené období může stále platit.

V takovém případě by měl BillingMeld uchovávat informaci, že další prodloužení je vypnuto, a zároveň rozpoznat datum konce již zaplaceného období.

Až po jeho skončení přístup přestane být aktivní, pokud nedojde k dalšímu potvrzenému prodloužení.

To je jeden z důvodů, proč nestačí jednoduchá hodnota subscription = true pro běžný billing.

Stav předplatného je vždy spojen s časem a událostmi životního cyklu.

Prodloužení je také samostatná kontrola

Předplatné nekončí při první platbě.

Server musí pochopit, zda došlo k dalšímu prodloužení a jestli je další zaplacené období skutečně potvrzeno obchodem.

BillingMeld sleduje takové změny a aktualizuje stav předplatného.

Pokud je prodloužení potvrzeno, právo na přístup pokračuje.

Pokud neproběhne platba nebo obchod již další období nepotvrzuje, systém by neměl jen předpokládat prodloužení přístupu.

Pro uživatele je to přirozené: přístup existuje tak dlouho, dokud je aktivní zaplacené předplatné.

Pro vývojáře znamená, že stejnou logiku prodloužení není třeba opakovaně implementovat v každé aplikaci.

Jak vypadá běžný scénář

Uživatel si v mobilní aplikaci zakoupí předplatné.

Klient obdrží informace o nákupu a předá potřebná data BillingMeld. Samotná zpráva však není ještě důvodem považovat nákup za finálně potvrzený.

BillingMeld prověřuje operaci přes odpovídající obchod.

Pokud App Store nebo Google Play potvrzují nákup a jeho stav odpovídá pravidlům produktu, BillingMeld zaznamená aktivní právo.

Poté připojená služba poskytne uživateli zaplacené možnosti.

Stav dál pokračuje již nezávisle na původní zprávě klienta.

Pokud se předplatné prodlouží, BillingMeld zaznamená nové zaplacené období.

Pokud uživatel vypne autoprodloužení, aktuální období pokračuje do svého konce.

Pokud dojde k vrácení nebo stažení operace, stav se opět změní.

V tomto schématu aplikace neukládá vlastní „pravdu“ o nákupu. Pracuje s potvrzeným a uloženým stavem BillingMeld.

Co se stane při změně zařízení

Model na serveru je zvlášť užitečný, když uživatel mění telefon nebo znovu instaluje aplikaci.

Právo na nákup by nemělo existovat pouze proto, že konkrétní kopie aplikace někdy viděla úspěšnou transakci.

A naopak, přeinstalace aplikace by neměla zrušit potvrzené právo uživatele.

Pokud je stav nákupu na serveru a spojen s potvrzenou obchodní operací, nové zařízení může získat aktuální stav prostřednictvím serveru.

To je další důvod, proč neukládat logiku přístupu výhradně v mobilní klientské aplikaci.

Co to přináší vývojářům

Pro tým, který vydává několik mobilních aplikací nebo pracuje současně s iOS a Androidem, se billing rychle stává samostatnou infrastrukturní úlohou.

Je třeba vzít v úvahu:

• různé formáty dat Apple a Google;

• ověření původního nákupu;

• prodlužování předplatného;

• ukončení zaplaceného období;

• vypnutí autoprodloužení;

• vrácení;

• stažení operace;

• opakovaná instalace aplikace;

• změna zařízení;

• obnovení nákupů;

• změny stavu bez zásahu klienta.

BillingMeld tyto logiky přesouvá do samostatného specializovaného vrstvy.

Servery produktů s ním pracují podle společné dohody a nemají samostatně vykládat všechny specifika jednotlivých obchodů.

To snižuje množství duplikovaného kódu a co je ještě důležitější, snižuje pravděpodobnost, že různé aplikace jedné společnosti budou různě chápat stejný platební scénář.

Hlavní je nikoliv potvrzení, ale aktuální právo

Nejvíce mě v této architektuře zaujala změna od kontroly jednotlivého nákupu k ověřování aktuálního stavu.

Historická platba sama o sobě ještě neodpovídá hlavní otázce produktu:

má uživatel nyní nárok na placenou funkci?

Operace může mít úspěšný počáteční nákup, ale již skončené období.

U předplatného může být vypnuto autoprodloužení, ale již zaplacený termín stále platí.

Existuje potvrzené prodloužení.

Může být proveden refund.

Může být operace stažena nebo odvolána obchodem.

Proto je hlavním objektem nikoliv potvrzení a původní odpověď klienta, ale aktuální právo uživatele na základě potvrzeného stavu nákupu.

A právě tento stav předává BillingMeld ostatním službám.

BillingMeld jako hranice mezi obchody a produkty

V důsledku vzniká velmi jasná architektonická hranice.

Na jedné straně jsou App Store a Google Play se svými formáty, událostmi, pravidly a životními cykly nákupů.

Na druhé stránky jsou aplikace a interní služby, které od nich často potřebují mnohem jednodušší odpověď: jaká práva má nyní uživatel.

Mezi nimi stojí BillingMeld.

Přijímá údaje z obchodů, ověřuje je, převádí na svůj vlastní model a poskytuje ostatní infrastruktuře již normalizovaný výsledek.

To umožňuje produktům nemuset znát všechny interní detaily jednotlivých platebních platforem.

Proč je to důležité pro uživatele

Pro uživatele by měla být správná fakturační architektura v ideálním případě zcela neviditelná.

Pokud je nákup potvrzen a zaplacené období platí, přístup by měl fungovat.

Pokud uživatel vypne další prodloužení, již zaplacené období by nemělo zmizet předčasně.

Pokud dojde k novému úspěšnému prodloužení, přístup by pokračoval.

Pokud obchod potvrdí refund nebo stažení, systém by měl správně odrážet změnu práva.

Při změně zařízení nebo znovuinstalaci aplikace by člověk neměl muset ručně dokazovat všem částem infrastruktury, že nákup skutečně existuje.

Závěrem platí jednoduché pravidlo:

klient oznámí nákup, obchod je vnější zdroj jeho stavu, BillingMeld ověřuje a normalizuje tento stav a ostatní služby o něm rozhodují již na základě potvrzených dat od BillingMeld.

Proto BillingMeld není jen dalším platebním modulem.

Je to serverová vrstva důvěry mezi mobilní aplikací, obchody Apple a Google a produkty, které musí přesně vědět, jaká placená práva momentálně uživatel má.

Více informací o projektu najdete na billingmeld.de.