Zakupy w aplikacji — istota, rodzaje i jak działa monetyzacja

Co to jest In-App Purchase?

In-App Purchase (IAP) — to technologia umożliwiająca sprzedaż cyfrowych towarów i usług wewnątrz aplikacji mobilnej. Płatności są przetwarzane przez App Store (na iOS) lub Google Play (na Android), które pobierają prowizję za przeprowadzenie transakcji. Deweloper otrzymuje środki pomniejszone o prowizję sklepu.

Apple pobiera prowizję w wysokości 30% (15% dla małych firm z dochodem do 1 miliona dolarów). Google Play również pobiera 30% (15% od pierwszego 1 miliona dolarów dochodu dewelopera). Od 2024 roku Google testuje program User Choice Billing, który umożliwia deweloperom korzystanie z alternatywnych systemów płatności.

IAP jest obowiązkowy do sprzedaży cyfrowych towarów w aplikacjach zgodnie z politykami App Store i Google Play. Towary fizyczne, usługi (zamawianie taksówki, dostawa jedzenia) i płatności peer-to-peer mogą korzystać z zewnętrznych systemów płatności.

Rodzaje In-App Purchase: consumable, non-consumable i subscription

App Store i Google Play obsługują trzy główne typy In-App Purchase. Każdy typ jest przeznaczony do różnych modeli monetyzacji. Wybór typu produktu wpływa na logikę przywracania zakupów, zarządzanie subskrypcjami i zachowanie przy ponownej instalacji aplikacji.

Consumable (zakupy jednorazowe)

Consumable — to towary, które można nabywać wielokrotnie i które są zużywane w trakcie użytkowania. Typowe przykłady: waluta w grze (monety, diamenty), dodatkowe życia, przyspieszacze, jednorazowe wzmocnienia. Consumable nie są przywracane po ponownej instalacji aplikacji — deweloper sam zarządza saldem każdego użytkownika na swoim serwerze.

Non-Consumable (zakupy trwałe)

Non-Consumable — to towary, które kupuje się raz i pozostają dostępne na zawsze. Przykłady: pełna wersja aplikacji, poziomy premium, odblokowanie filtrów, usunięcie reklam. Produkty non-consumable są przywracane przez Restore Purchases API: po ponownej instalacji użytkownik może odzyskać wcześniej kupione towary bez ponownej płatności.

Auto-Renewable Subscription (subskrypcja z automatycznym odnowieniem)

Auto-Renewable Subscription — to regularne płatności za dostęp do treści lub usługi na określony okres (tydzień, miesiąc, rok). Subskrypcja automatycznie się odnawia, dopóki użytkownik jej nie anuluje w ustawieniach konta. Sklepy udostępniają powiadomienia serwerowe (App Store Server Notifications, Google Play Developer Notifications) o zmianie statusu subskrypcji: odnowienie, wygaśnięcie, zwrot.

Konfiguracja IAP w App Store Connect i Google Play Console

Konfiguracja In-App Purchase rozpoczyna się w panelach dewelopera: App Store Connect dla iOS i Google Play Console dla Androida. Dla każdego produktu podaje się identyfikator (Product ID), nazwę, opis, typ i cenę w dolarach amerykańskich z automatyczną konwersją na waluty regionalne. Po utworzeniu produkt przechodzi moderację sklepu.

W App Store Connect produkty IAP tworzy się w sekcji Features → In-App Purchases. Dla każdego produktu wybiera się typ (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) i wypełnia zlokalizowane nazwy. Dla subskrypcji dodatkowo konfiguruje się grupy (Subscription Groups) — grupy wzajemnie zastępowalnych subskrypcji.

W Google Play Console managed products konfiguruje się w sekcji Monetise → Products → In-app products. Google używa terminów Managed Product (odpowiednik non-consumable) i Subscription. Dla zakupów consumable na Androidzie używa się osobnego flagi consume, która resetuje produkt do ponownego zakupu.

Moderacja produktów IAP trwa średnio 24–48 godzin w App Store i kilka godzin w Google Play. Zmiany cen są stosowane natychmiastowo bez ponownej moderacji. Product ID nie można zmienić po utworzeniu — można tylko usunąć i utworzyć ponownie.

Server-side receipt validation i ochrona przed oszustwami

Receipt validation (weryfikacja paragonu) — obowiązkowy etap przetwarzania In-App Purchase. Aplikacja kliencka wysyła paragon (receipt) na własny serwer, serwer weryfikuje go przez API Apple (https://buy.itunes.apple.com) lub Google (https://androidpublisher.googleapis.com) i dopiero po pomyślnej walidacji przyznaje towar użytkownikowi.

Bez weryfikacji serwerowej osoba atakująca może podmienić odpowiedź sklepu i otrzymać towar za darmo. Client-side validation jest niebezpieczna, ponieważ wykonywana jest w środowisku kontrolowanym przez użytkownika. Weryfikacja serwerowa gwarantuje, że paragon jest autentyczny i płatność przebiegła pomyślnie. Dla Apple weryfikacja odbywa się przez endpoint verifyReceipt (produkcyjny lub sandbox), dla Google — przez Android Publisher API. Oba sklepy zwracają potwierdzenie w formacie JSON.

Apple zwraca w paragonie dane o zakupie: product_id, transaction_id, purchase_date, expiration_date (dla subskrypcji). Google zwraca analogiczne pola przez API Purchases.products.get lub Purchases.subscriptions.get. Serwer powinien przechowywać transaction_id każdego paragonu i odrzucać ponowne żądania z tym samym ID w celu ochrony przed atakami typu replay.

Integracja IAP w aplikacji mobilnej w Swift i Kotlin

Integracja In-App Purchase wymaga podłączenia bibliotek platformowych: StoreKit 2 na iOS i Billing Library 7+ na Android. API umożliwiają pobieranie listy produktów, inicjowanie zakupu, przetwarzanie wyniku i przywracanie wcześniej nabytych towarów.

Swift — StoreKit 2 na iOS 17+

import StoreKit

func purchaseProduct(productID: String) async throws {
    guard let product = try await Product.products(for: [productID]).first else { return }
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        let transaction = try verification.payloadValue
        await validateReceipt(transaction)
        await transaction.finish()
    default:
        break
    }
}

Kotlin — Billing Library 7

import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingFlowParams

val billingClient = BillingClient.newBuilder(context)
    .setListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases?.forEach { purchase ->
                validateReceipt(purchase)
            }
        }
    }
    .build()

val params = BillingFlowParams.newBuilder()
    .setProductDetails(productDetails)
    .build()
billingClient.launchBillingFlow(activity, params)

Server-side receipt validation (Node.js)

const response = await fetch('https://buy.itunes.apple.com/verifyReceipt', {
    method: 'POST',
    body: JSON.stringify({
        'receipt-data': receiptBase64,
        'password': 'SHARED_SECRET'
    })
})

const data = await response.json()
if (data.status === 0) {
    // Paragon potwierdzony — przyznajemy towar
    await grantProduct(data.receipt.product_id)
}

Najlepsze praktyki monetyzacji przez In-App Purchase

Monetyzacja przez In-App Purchase wymaga przemyślanej strategii cenowej i UX. Użytkownicy są bardziej skłonni do pierwszego zakupu, jeśli zaproponuje się im atrakcyjny pakiet startowy (starter pack) w niskiej cenie. Apple i Google zalecają pokazywanie ceny produktu przed momentem potwierdzenia zakupu.

Subscription onboarding — krytyczny etap konwersji. Pokaż użytkownikowi wartość subskrypcji przed prośbą o płatność: darmowy okres próbny, porównanie planów, listę korzyści. Według badań darmowy okres próbny (free trial) zwiększa konwersję płacących użytkowników o 25–40%.

Restore Purchases jest obowiązkowy dla produktów non-consumable i subskrypcji. Przycisk przywracania powinien być dostępny w ustawieniach aplikacji lub na ekranie płatności. Google i Apple mogą odrzucić aplikację, jeśli przywracanie zakupów nie jest zaimplementowane dla odpowiednich typów IAP.

Grace Period — okres odroczenia dla subskrypcji, w którym użytkownik zachowuje dostęp po nieudanej płatności. iOS i Android obsługują grace period do 30 dni. Włączenie grace period zmniejsza wskaźnik rezygnacji (churn rate) o 10–15%.

Testy A/B cen IAP — ważna praktyka monetyzacji. App Store Connect obsługuje lokalne ceny (Price Tiers) z możliwością zmiany ceny bez ponownej moderacji produktu. Google Play Console umożliwia skonfigurowanie do 5 planów bazowych z różnymi cenami dla jednego produktu subskrypcyjnego. Zaleca się testowanie co najmniej dwóch punktów cenowych: aktualnego i nowego. Testowanie przeprowadza się przez 2–4 tygodnie na próbie co najmniej 1000 użytkowników na każdy punkt cenowy.

Store Review i zarządzanie odrzuceniem — obowiązkowy etap publikacji aplikacji z IAP. Apple szczególnie dokładnie sprawdza aplikacje z auto-renewable subscriptions: należy udostępnić testowe konto z aktywną subskrypcją, pokazać ekran anulowania subskrypcji i zaimplementować Restore Purchases. Google Play jest mniej rygorystyczny, ale wymaga potwierdzenia praw do treści cyfrowej. Zaleca się dodanie notatki dla recenzenta (Review Notes) z opisem logiki IAP.