Zkratka proIn-App Purchasein-ep nákupTakéIAP, nákup v aplikaci, in app purchase, in-app purchasesPokročilý
Definice
In-app nákup je platba za digitální obsah nebo funkci uskutečněná přímo uvnitř mobilní aplikace přes platební systém obchodu, tedy App Store nebo Google Play. Obchod vyřídí platbu, účtenku i vrácení peněz, strhne si provizi a aplikaci vrátí podepsaný doklad, podle kterého odemkne zakoupený obsah.
Než se na to spolehnete: Konkrétní výše provizí (30 %, snížených 15 %) a pravidla vynucující fakturaci obchodu se kvůli DMA a soudním sporům rychle mění, proto jsou v textu uvedeny s výhradou. Zdroje: nemám v povoleném seznamu domény developer.apple.com ani developer.android.com, kde je primární dokumentace StoreKitu a Play Billing; uvedené odkazy jsou proto jen kořeny sekcí a část z nich nemusí být tematicky přesná (MDN
Co si uživatel v aplikaci vlastně kupuje
In-app nákupy se dělí do několika typů a od typu se odvíjí celá implementace. Spotřební nákup (herní měna, kredity) lze koupit opakovaně a po použití zmizí. Nespotřební nákup (odemčení pro verze, odstranění reklam) se kupuje jednou a platí navždy, takže musí jít obnovit i na novém zařízení. Automaticky obnovované předplatné se strhává v cyklu, dokud ho uživatel nezruší, a přináší nejvíc stavů k ošetření: zkušební období, odklad platby, upgrade a downgrade tarifu, obnovu po výpadku karty.
Kudy tečou peníze a kdo drží účtenku
Aplikace při in-app nákupu nikdy nevidí číslo karty. Volá rozhraní obchodu (StoreKit na iOS, Google Play Billing na Androidu), obchod zobrazí vlastní platební dialog, provede transakci a vrátí podepsanou transakci nebo token. Teprve tenhle doklad je důkaz o nákupu.
Ověření na zařízení jde obejít podvrženou knihovnou, proto se doklad posílá na vlastní backend a ověřuje se serverovým voláním proti API obchodu. Server pak vede záznam o nároku uživatele. Nezbytným krokem je také potvrzení transakce (finish, acknowledge): dokud aplikace nákup nepotvrdí, obchod ho po několika dnech automaticky vrátí zákazníkovi.
Provize a kdy se platebnímu systému obchodu nelze vyhnout
Obchody si z ceny berou provizi, standardně 30 %, se sníženou sazbou pro malé vývojáře a pro předplatné trvající déle než rok. Pravidla obou obchodů vyžadují použití jejich fakturace všude, kde jde o digitální obsah spotřebovaný v aplikaci. Fyzické zboží, doprava, jízdenky nebo služby konzumované mimo aplikaci naopak přes in-app nákup jít nesmějí a řeší je běžná platební brána. Regulace, zejména evropský Digital Markets Act, tenhle režim postupně uvolňuje a povoluje odkaz na externí platbu, ale konkrétní podmínky se mění a je nutné číst aktuální znění pravidel obchodu.
Co in-app nákupy dělají s produktem
Model in-app nákupů posouvá těžiště z ceny za stažení na chování uživatele po instalaci. Aplikace je zdarma, měří se aktivace, konverze na platící a hlavně retenční míra, protože předplatné vydělá teprve po několika cyklech. Součástí návrhu je paywall: obrazovka s nabídkou, jejíž umístění v uživatelské cestě ovlivní tržby víc než samotná cena. Testovat se dá cenovými hladinami definovanými v konzoli obchodu, ne libovolnou částkou z kódu.
Kde implementace nejčastěji selže
- Chybějící obnova nákupů. Bez tlačítka pro obnovení nespotřebních nákupů aplikace neprojde revizí v App Storu.
- Nároky vázané jen na zařízení. Bez účtu na backendu uživatel po přechodu z iOS na Android o zaplacené předplatné přijde.
- Ignorované serverové notifikace. Zrušení, refundace nebo vypršení se aplikace nedozví, pokud backend neposlouchá notifikace obchodu.
- Testování jen na produkci. Oba obchody nabízejí sandbox a testovací účty; bez nich se chyby v obnově předplatného objeví až u zákazníků.
Příklady z praxe
Předplatné fitness aplikace s týdenní zkušební dobou
Aplikace nabídne sedmidenní trial a poté měsíční předplatné. Uživatel potvrdí nákup, obchod vrátí transakci a backend si uloží datum vypršení. Když karta selže, obchod přejde do stavu odkladu (grace period) a pošle serverovou notifikaci; backend nechá přístup ještě několik dní otevřený, místo aby uživatele okamžitě odstřihl.
Serverové ověření dokladu z Google Play
Aplikace pošle na backend purchase token a identifikátor produktu. Backend se zeptá API obchodu, zda transakce existuje a v jakém je stavu, a teprve pak uživateli přizná nárok a nákup potvrdí. Bez tohoto kroku by stačilo podvrhnout odpověď knihovny přímo v zařízení.
POST /api/iap/verify { "platform": "android", "productId": "pro_monthly", "purchaseToken": "opaque-token-z-billing-api" } // backend -> Google Play Developer API // -> { "expiryTimeMillis": "...", "paymentState": 1 } // -> ulozit narok, potom acknowledge()
Časté omyly
- MýtusKdyž už mám platební bránu na webu, použiju ji i v mobilní aplikaci a ušetřím provizi.
- Ve skutečnostiPravidla App Storu i Google Play vyžadují u digitálního obsahu spotřebovaného v aplikaci jejich vlastní fakturaci. Vlastní brána v tomto případě znamená zamítnutí revize nebo stažení aplikace. Vlastní brána je v pořádku u fyzického zboží a služeb mimo aplikaci.
- MýtusOvěření nákupu si udělá aplikace sama, backend na to nepotřebuju.
- Ve skutečnostiOvěření pouze v klientovi jde obejít upravenou knihovnou nebo emulátorem platby. Doklad je proto potřeba ověřit serverovým voláním proti API obchodu a nárok uživatele držet na backendu.
- MýtusJakmile uživatel zaplatí, je hotovo.
- Ve skutečnostiNepotvrzená transakce se po několika dnech automaticky vrátí zákazníkovi. Předplatné navíc žije dál: obnovuje se, přechází do odkladu, ruší se a může být refundováno, což backend musí zachytit ze serverových notifikací.
Časté dotazy
- Kolik si obchody z in-app nákupu berou?
- Standardní provize App Storu i Google Play je 30 % z ceny in-app nákupu. Obě platformy nabízejí sníženou sazbu 15 % pro menší vývojáře v rámci svých programů a pro předplatné po prvním roce trvání zákazníka. Sazby a podmínky programů se ale mění a v Evropské unii je ovlivňuje regulace digitálních trhů, proto je vždy nutné ověřit aktuální znění obchodních podmínek dané platformy. Do kalkulace patří i to, že provize se počítá z ceny včetně daně podle pravidel konkrétního obchodu.
- Kdy nemusím in-app nákup použít a stačí běžná platební brána?
- Běžná platební brána stačí tam, kde uživatel platí za fyzické zboží, dopravu, vstupenky, jízdné nebo za službu poskytnutou mimo aplikaci reálnou osobou. Typicky tedy e-shop, taxi, doručení jídla nebo rezervace ubytování. Naopak digitální obsah, který se spotřebovává uvnitř aplikace, jako herní měna, odemčení funkcí, prémiový obsah nebo předplatné aplikace, musí jít přes fakturaci obchodu. Hraniční případy, například B2B software prodávaný firmám, stojí za to konzultovat s aktuálním zněním pravidel platformy před vývojem.
- Jak se in-app nákupy testují před vydáním?
- In-app nákupy se testují v sandboxu obou platforem. Na iOS se používají sandboxové Apple ID a testovací prostředí StoreKitu, kde se předplatné obnovuje ve zrychlených intervalech, takže roční plán projde cyklem během minut. Na Androidu slouží licencovaní testeři a interní testovací kanál v Play Console, kde jsou nákupy bezplatné. Testovat je potřeba nejen úspěšný nákup, ale hlavně obnovu nákupů na novém zařízení, zrušení, refundaci, výpadek sítě uprostřed transakce a chování aplikace při nepotvrzené transakci.
- Kde má být uložený nárok uživatele na zaplacený obsah?
- Nárok uživatele patří na backend, navázaný na jeho účet, nikoli jen do lokálního úložiště zařízení. Backend přijme doklad z aplikace, ověří ho proti API obchodu a uloží, do kdy předplatné platí nebo co je odemčeno. Takové řešení umožní přístup ke stejnému obsahu z webu i z jiné platformy, přežije reinstalaci aplikace a dovolí reagovat na serverové notifikace o zrušení či refundaci. Ukládání nároku pouze do zařízení vede k reklamacím typu zaplatil jsem a přišel jsem o to.
Zdroje
- In-app purchases(otevře se v novém okně)
- Google Play Billing(otevře se v novém okně)
- Digital Markets Act(otevře se v novém okně)
- In-app purchase(otevře se v novém okně)
Související pojmy
