Google Play Billing

Google Play Billing je jednou z technologií platformy Android, které používám v případech, kdy aplikace potřebuje placenou funkcionalitu, jednorázové nákupy, předplatné nebo spolehlivý způsob odemykání prémiových funkcí.

Používám ji jako součást architektury aplikace, nikoli jako samostatné tlačítko pro platbu, které pouze vrátí úspěch nebo neúspěch.

Produkční implementace plateb musí řešit stav nákupu, logiku oprávnění, opětovné připojení, obnovení nákupů, zrušení, chybové stavy a vztah mezi Google Play a vlastním lokálním nebo backendovým stavem aplikace.

Jak používám Google Play Billing

Google Play Billing používám například pro:

• jednorázové nákupy,
• odemykání prémiových funkcí,
• nákupy pro odstranění reklam,
• předplatné,
• kontrolu oprávnění,
• obnovování existujících nákupů,
• synchronizaci stavu monetizace,
• potvrzování nákupů,
• zpracování chyb platebního systému.

Konkrétní implementace závisí na obchodním modelu aplikace.

U řady utilit může být jednorázový trvalý nákup pro odstranění reklam nebo odemknutí prémiových funkcí vhodnější než opakované předplatné.

Monetizační model by měl odpovídat skutečné hodnotě, kterou aplikace uživateli poskytuje.

Platby jako stav aplikace

Nákup nevnímám jako dočasnou událost v uživatelském rozhraní.

Dokončená transakce obvykle mění stav aplikace.

Například:

uživatel zdarma
→ nákup
→ prémiové oprávnění
→ prémiové funkce aktivní

Aplikace musí být schopná toto oprávnění znovu určit i později.

To znamená, že platební logika musí přežít:

• restarty aplikace,
• změnu zařízení,
• reinstalaci,
• znovuvytvoření Activity,
• dočasné výpadky sítě.

Uživatelské rozhraní by mělo odrážet ověřený stav oprávnění, nikoli spoléhat na boolean uložený v paměti ve chvíli, kdy uživatel stiskne tlačítko.

Konfigurace produktů

Platební produkty jsou definovány v Google Play a aplikace na ně odkazuje prostřednictvím jejich identifikátorů.

Tyto identifikátory udržuji centralizované a nerozmisťuji syrové řetězce po celém kódu.

Aplikace může například definovat produkty pro:

• trvalé odstranění reklam,
• prémiovou funkcionalitu,
• volitelná odemknutí funkcí,
• opakovaná předplatná.

Aplikace pak může tyto produkty mapovat na vlastní interní model oprávnění.

Tím zůstává konfigurace Google Play oddělená od širší aplikační logiky.

Načítání informací o produktech

Před zobrazením nákupu aplikace obvykle potřebuje informace o dostupném produktu.

Může jít například o:

• dostupnost produktu,
• cenu,
• fakturační období,
• dostupné možnosti nákupu.

Tyto informace načítám dynamicky a neukládám hodnoty, jako jsou ceny, natvrdo do uživatelského rozhraní.

Cena se může lišit podle země, měny a konfigurace Google Play.

Obchod by měl zůstávat autoritativním zdrojem obchodních informací o produktu.

Průběh nákupu

Platební proces obvykle začíná až po explicitní akci uživatele.

Zjednodušený průběh může vypadat takto:

1. načíst informace o produktu,
2. zobrazit odpovídající nabídku,
3. spustit nákupní proces Google Play,
4. přijmout výsledek,
5. ověřit stav nákupu,
6. udělit odpovídající oprávnění.

Prezentaci nákupu odděluji od logiky, která rozhoduje, co má uživatel skutečně získat.

Google Play zpracuje transakci.

Aplikace zpracuje výsledné oprávnění.

Stavy nákupu

Odpověď platebního systému by neměla být automaticky považována za dokončený nákup.

Transakce může existovat v různých stavech.

Aplikace musí rozlišovat například mezi:

• úspěšně zakoupeno,
• čekající nákup,
• zrušeno,
• selhání.

To je důležité, protože některé transakce nemusí být dokončeny okamžitě.

Prémiová funkcionalita by měla být zpřístupněna pouze tehdy, pokud to skutečný stav nákupu dovoluje.

Čekající nákupy

Některé platební metody mohou vést k tomu, že nákup zůstane po určitou dobu ve stavu čekání.

Platební logiku proto navrhuji tak, aby čekající transakce okamžitě neodemkla placenou funkcionalitu.

Aplikace může uživateli oznámit, že nákup čeká na dokončení, a oprávnění aktualizovat až ve chvíli, kdy Google Play nahlásí dokončený stav.

Tím se zabrání zpřístupnění placených funkcí pro transakci, která ještě nebyla finalizována.

Potvrzení nákupu

Dokončené nákupy je potřeba zpracovat podle požadavků platební platformy.

Potvrzení nákupu zahrnuji do standardního workflow zpracování nákupu a nepovažuji úspěšný callback za konec celé transakce.

Robustní implementace sleduje, zda už byl nákup zpracován, aby stejná událost zbytečně nespustila duplicitní aplikační akce.

Oprávnění

Preferuji uvažovat v pojmech oprávnění namísto samotných platebních produktů.

Platební produkt je něco, co si uživatel koupí.

Oprávnění popisuje, co mu tento nákup zpřístupní uvnitř aplikace.

Například:

Produkt:
remove_ads

Oprávnění:
ads_disabled = true

Toto rozlišení je s rostoucí monetizací stále užitečnější.

Více různých produktů nebo konfigurací předplatného může v budoucnu mapovat na stejnou aplikační schopnost.

Zbytek aplikace by se měl ideálně zajímat o oprávnění, nikoli o interní detaily transakce v obchodě.

Odstranění reklam

Jedním z běžných scénářů, které implementuji, je jednorázový trvalý nákup pro odstranění reklam.

Zjednodušená monetizační architektura může vypadat takto:

uživatel zdarma
→ AdMob aktivní

oprávnění pro odstranění reklam
→ AdMob deaktivován

Reklamní subsystém nemusí rozumět celé implementaci Google Play Billing.

Stačí mu vědět, zda uživatel aktuálně disponuje oprávněním, které reklamy vypíná.

Tím zůstává platební a reklamní logika čistě oddělená.

Integrace Google Mobile Ads

Platby a reklama musí často fungovat společně.

Jakmile se oprávnění pro odstranění reklam aktivuje, měla by na to aplikace reagovat konzistentně.

Může jít například o:

• zastavení nových požadavků na reklamy,
• skrytí kontejnerů pro bannery,
• zabránění zobrazení interstitial reklam,
• deaktivaci app open reklam,
• skrytí výzev k nákupu tam, kde je to vhodné.

Preferuji centrální stav monetizace, který může sledovat jak platební vrstva, tak reklamní vrstva.

Tím se zabrání tomu, aby každá obrazovka implementovala vlastní interpretaci toho, zda se mají reklamy zobrazovat.

Obnovení nákupů

Uživatelé by neměli platit znovu jen proto, že aplikaci přeinstalují nebo ji používají na jiném zařízení se stejným způsobilým účtem Google Play.

Proto obnovování nákupů zahrnuji přímo do platební architektury.

Ve vhodných okamžicích může aplikace dotázat Google Play na relevantní nákupy a znovu sestavit aktuální stav oprávnění.

To zároveň chrání před tím, že se lokální stav aplikace stane zastaralým nebo bude smazán.

Kontrola oprávnění při spuštění

Při startu aplikace může lokální stav zajistit okamžitě plynulejší uživatelský zážitek, ale obchod zůstává důležitý pro určení skutečného stavu nákupu.

Inicializaci plateb proto navrhuji tak, aby aplikace dokázala svůj stav oprávnění znovu porovnat s Google Play.

Konkrétní strategie závisí na aplikaci a na tom, zda je součástí architektury backend.

Důležité je, aby oprávnění nebylo trvale závislé na jediné lokální preferenci, kterou už nikdy nelze opravit.

Lokální persistence

Lokální persistence může být stále užitečná.

Může například aplikaci umožnit zapamatovat si, že uživatel dříve disponoval prémiovým přístupem, zatímco se navazuje spojení s platební službou.

Rozlišuji však mezi:

• cachovaným stavem oprávnění,
• autoritativním stavem nákupu.

Cache zlepšuje chování při spuštění.

Pokud je vyžadováno ověření, neměla by se stát jediným zdrojem pravdy.

Ověření na backendu

U aplikací s hodnotnějšími transakcemi nebo vyššími bezpečnostními požadavky lze informace o nákupech ověřovat také prostřednictvím backendu.

Serverová architektura může pomoci například s:

• správou oprávnění,
• stavem napříč zařízeními,
• odolností vůči podvodům,
• stavem předplatného,
• centralizovanými uživatelskými účty,
• historií nákupů.

Ne každá malá aplikace vyžaduje backendový platební systém.

Architekturu volím podle hodnoty a složitosti produktu.

Připojení k platební službě

Platební služba je externí systém vůči aplikaci.

Připojení může být:

• nedostupné,
• přerušené,
• dočasně nefunkční,
• později znovu navázané.

Připojení k platební službě proto považuji za asynchronní stav a nepředpokládám, že bude trvale dostupné.

Aplikace by se měla z problémů s připojením umět zotavit bez nutnosti úplného restartu.

Zpracování selhání

Platební systém může selhat z celé řady důvodů.

Patří mezi ně například:

• problémy s konektivitou,
• nedostupné produkty,
• problémy se službami Google Play,
• zrušení uživatelem,
• neplatná konfigurace aplikace,
• dočasné chyby platebního systému.

Tyto stavy zpracovávám explicitně.

Selhání nákupu nesmí aplikaci dostat do částečně prémiového stavu.

Pokud je od uživatele vyžadována nějaká akce, měl by zároveň obdržet jasnou zpětnou vazbu.

Zrušení uživatelem

Zrušený nákup je běžný výsledek.

Nejde o chybu aplikace.

Nákupní proces proto navrhuji tak, aby zrušení jednoduše vrátilo aplikaci do předchozího stavu bez agresivních chybových hlášení nebo opakovaných výzev k nákupu.

Uživatel by měl mít plnou kontrolu nad tím, zda transakci dokončí.

Idempotentní zpracování nákupů

Callback nákupu může být doručen více než jednou nebo může být stav oprávnění znovu sestaven při pozdější synchronizaci.

Zpracování nákupu proto navrhuji tak, aby opakovaná aplikace stejné platné transakce nezpůsobila nesprávné duplicitní efekty.

Například dvojnásobná aktivace prémiového přístupu by měla stále vést pouze k jednomu prémiovému oprávnění.

To je zvlášť důležité v případech, kdy je součástí architektury backend nebo další logika odměn.

Předplatné

U aplikací, které poskytují opakovanou hodnotu, může Google Play Billing podporovat také předplatné.

Logika předplatného vyžaduje další pozornost, protože přístup se může v čase měnit.

Možné stavy mohou zahrnovat:

• aktivní,
• obnovené,
• zrušené, ale stále platné do konce fakturačního období,
• vypršené.

Aplikace by měla přístup určovat podle skutečného období oprávnění a neměla by každé zrušení automaticky vykládat jako okamžitou ztrátu přístupu.

Jednorázové nákupy vs. předplatné

Předplatné nepoužívám automaticky jen proto, že může generovat opakované příjmy.

Monetizační model by měl odpovídat produktu.

Trvalá funkce utilitní aplikace může být vhodnější pro jednorázový nákup.

Průběžně udržovaná služba s trvalými provozními náklady může naopak odůvodňovat opakované platby.

Dobrá monetizační architektura začíná u modelu hodnoty, nikoli u platebního API.

Uživatelské rozhraní nákupu

Rozhraní by mělo jasně komunikovat:

• co si uživatel kupuje,
• zda jde o opakovanou platbu,
• jaká funkcionalita bude odemčena,
• cenu zobrazenou Google Play.

Nevytvářím nákupní obrazovky, které záměrně zamlžují povahu transakce.

Při práci s penězi je důvěra mimořádně důležitá.

Jetpack Compose

V moderních Android aplikacích integruji platební stav s Jetpack Compose.

Platební vrstva může poskytovat aplikační stav, například:

• dostupné produkty,
• stav načítání,
• prémiové oprávnění,
• průběh nákupu,
• chyby.

Compose pak může z tohoto stavu vykreslit odpovídající rozhraní.

Přímé operace s billing klientem se snažím držet mimo composable funkce.

Tím se zachovává čistší oddělení mezi vykreslováním UI a imperativním API Google Play Billing.

ViewModel a správa stavu

Platební stav často patří do aplikačního správce stavu nebo samostatné billing komponenty, nikoli přímo do jedné konkrétní obrazovky.

To může zabránit problémům v situacích, kdy:

• dojde ke znovuvytvoření Activity,
• uživatel přejde mezi obrazovkami,
• výsledek nákupu dorazí až po navigaci.

Strukturovaný model stavu zároveň usnadňuje testování uživatelského rozhraní.

Životní cyklus aplikace

Platební interakce existují v rámci životního cyklu Androidu.

Počítám s:

• opětovným vytvořením Activity,
• restartem aplikace,
• přechody na pozadí,
• opětovným připojením.

Platební systém by neměl předpokládat, že stejná instance obrazovky bude existovat po celý životní cyklus transakce.

Trvalé oprávnění a centrální platební stav tuto závislost snižují.

Coroutines a asynchronní práce

Platební operace jsou asynchronní.

V aplikacích v Kotlinu je proto pečlivě integruji do širší asynchronní architektury.

Coroutines mohou pomoci koordinovat:

• inicializaci,
• načítání produktů,
• aktualizaci stavu,
• persistenci,
• synchronizaci s backendem.

Uživatelské rozhraní by při komunikaci s Google Play nemělo blokovat.

Bezpečnost

Stav nákupu má přímé finanční dopady, proto slepě nedůvěřuji libovolným příznakům uloženým na klientovi.

Podle typu aplikace zvažuji:

• validaci,
• ověření na backendu,
• odolnost vůči manipulaci,
• autoritativní zdroje oprávnění.

U jednoduchých aplikací s nízkým rizikem nemusí být plně serverový systém oprávnění nutný.

U hodnotnější funkcionality by však bylo nevhodné spoléhat se výhradně na lokálně upravitelnou hodnotu.

Nákupy neukládám pouze jako jednoduchý boolean

Vzorec typu:

premium = true

uložený jednou po nákupu může být užitečný jako cache, ale neměl by nutně představovat celou platební architekturu.

Robustnější návrh rozumí tomu, proč je prémiový stav aktivní.

Může jít například o:

• trvalý nákup,
• aktivní předplatné,
• jiný zdroj oprávnění.

To výrazně usnadňuje budoucí změny monetizace.

Testování

Platební procesy testuji odděleně od produkčních transakcí.

Implementace musí zvládnout víc než jen úspěšný nákup.

Ověřuji chování například pro:

• úspěšný nákup,
• zrušení,
• čekající stav,
• nedostupné produkty,
• opětovné připojení,
• obnovené nákupy,
• již vlastněné produkty,
• aktivaci odstranění reklam.

Testovat okrajové monetizační scénáře před vydáním je výrazně bezpečnější než je objevovat až prostřednictvím platících uživatelů.

Vývojová a produkční konfigurace

Platební produkty závisí také na konfiguraci mimo zdrojový kód.

Identifikátory produktů v aplikaci a konfiguraci Google Play udržuji synchronizované a pečlivě ověřuji release prostředí.

Platební implementace může být technicky správná, a přesto selhávat, pokud balíček aplikace, produkt nebo release konfigurace neodpovídají nastavení obchodu.

Logování

Problémy s platbami se bez kvalitních logů často obtížně diagnostikují.

Při vývoji a diagnostice zaznamenávám relevantní události, například:

• inicializaci billing systému,
• výsledky dotazů na produkty,
• změny stavu nákupu,
• selhání při zpracování.

Zbytečně neloguji citlivé údaje o transakcích.

Logy by měly pomoci diagnostikovat workflow, aniž by zpřístupňovaly data, která do nich nepatří.

Defenzivní platební architektura

Google Play Billing je externí systém.

Proto počítám s neočekávanými situacemi.

Aplikace by měla zvládnout případy, kdy:

• je Google Play dočasně nedostupný,
• vypadne síť,
• stav dorazí později, než se očekávalo,
• produkt nelze načíst,
• uživatel už danou položku vlastní.

Aplikace by měla zůstat stabilní bez ohledu na aktuální stav platebního subsystému.

Oddělení odpovědností

Preferuji rozdělení platební logiky do jasných vrstev.

Například:

Google Play Billing
→ stav nákupu
→ vrstva oprávnění
→ funkce aplikace

To je čistší než nechat jednotlivé obrazovky, aby se samy dotazovaly Google Play a dělaly vlastní rozhodnutí o monetizaci.

Zároveň to usnadňuje pozdější výměnu, rozšíření nebo testování platební vrstvy.

Google Play Billing v mém technologickém stacku

Google Play Billing běžně používám společně s:

• Androidem,
• Kotlinem,
• Jetpack Compose,
• Google Mobile Ads / AdMob,
• lokální persistencí,
• správou aplikačního stavu,
• backendovými službami tam, kde jsou potřeba.

Tyto technologie společně tvoří kompletní architekturu mobilní monetizace namísto jediného tlačítka pro nákup.

Proč používám Google Play Billing

Google Play Billing používám proto, že placená funkcionalita na Androidu potřebuje bezpečné a standardizované propojení s ekosystémem Google Play.

Jeho hodnota nespočívá pouze v tom, že dokáže zobrazit platební dialog.

Správná integrace umožňuje aplikaci spolehlivě udržovat stav oprávnění, obnovovat nákupy, reagovat na změny životního cyklu a čistě propojit platební systém s funkcemi, jako je prémiový přístup nebo odstranění reklam.

Takto k integraci plateb přistupuji: jako k trvalému subsystému aplikace s jasně definovaným stavem, zpracováním chyb a důvěrou uživatele zabudovanou přímo do architektury.