Alkalmazáson belüli vásárlás — lényeg, vásárlási típusok és hogyan működik a monetizáció

Mi az In-App Purchase?

In-App Purchase (IAP) — olyan technológia, amely lehetővé teszi digitális termékek és szolgáltatások értékesítését a mobilalkalmazáson belül. A fizetéseket az App Store (iOS-en) vagy a Google Play (Androidon) dolgozza fel, amelyek jutalékot számítanak fel a tranzakció lebonyolításáért. A fejlesztő a bolti jutalék levonása után kapja meg a pénzt.

Az Apple 30% jutalékot számít fel (15% az 1 millió dollárig terjedő bevétellel rendelkező kisvállalkozások számára). A Google Play szintén 30%-ot számít fel (15% a fejlesztői bevétel első 1 millió dollárjára). 2024-től a Google teszteli a User Choice Billing programot, amely lehetővé teszi a fejlesztők számára alternatív fizetési rendszerek használatát.

Az IAP kötelező a digitális termékek alkalmazásokon belüli értékesítéséhez az App Store és a Google Play irányelvei szerint. Fizikai termékek, szolgáltatások (taxirendelés, ételkézbesítés) és peer-to-peer fizetések használhatnak harmadik féltől származó fizetési rendszereket.

Az In-App Purchase típusai: consumable, non-consumable és subscription

App Store és a Google Play három fő In-App Purchase típust támogat. Mindegyik típus más-más monetizációs modellhez készült. A terméktípus kiválasztása befolyásolja a vásárlások visszaállításának logikáját, az előfizetések kezelését és az alkalmazás újratelepítésekor mutatott viselkedést.

Consumable (fogyasztható vásárlások)

Consumable — olyan termékek, amelyek többször megvásárolhatók és használat közben elfogynak. Tipikus példák: játékpénz (érmék, gyémántok), plusz életek, gyorsítók, fogyasztható erősítők. A consumable termékek nem állnak vissza az alkalmazás újratelepítésekor — a fejlesztő maga kezeli az egyes felhasználók egyenlegét a saját szerverén.

Non-Consumable (nem fogyasztható vásárlások)

Non-Consumable — olyan termékek, amelyeket egyszer vásárolnak meg és örökre elérhetők maradnak. Példák: az alkalmazás teljes verziója, prémium szintek, szűrők feloldása, hirdetések eltávolítása. A non-consumable termékek visszaállíthatók a Restore Purchases API-n keresztül: újratelepítés után a felhasználó visszakaphatja a korábban megvásárolt termékeket ismételt fizetés nélkül.

Auto-Renewable Subscription (automatikusan megújuló előfizetés)

Auto-Renewable Subscription — rendszeres fizetések egy meghatározott időszakra (hét, hónap, év) szóló tartalomhoz vagy szolgáltatáshoz való hozzáférésért. Az előfizetés automatikusan megújul, amíg a felhasználó le nem mondja a fiókbeállításokban. A boltok szerverértesítéseket (App Store Server Notifications, Google Play Developer Notifications) biztosítanak az előfizetés állapotának változásáról: megújítás, lejárat, visszatérítés.

IAP beállítása az App Store Connectben és a Google Play Console-ban

Beállítás Az In-App Purchase a fejlesztői panelekben kezdődik: App Store Connect iOS-hez és Google Play Console Androidhoz. Minden termékhez meg kell adni egy azonosítót (Product ID), nevet, leírást, típust és árat USA dollárban, automatikus átváltással a regionális pénznemekre. Létrehozás után a termék átesik a bolt moderációján.

Az App Store Connectben az IAP termékek a Features → In-App Purchases szakaszban hozhatók létre. Minden termékhez ki kell választani a típust (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) és ki kell tölteni a lokalizált neveket. Az előfizetésekhez további csoportok (Subscription Groups) konfigurálhatók — egymással felcserélhető előfizetések csoportjai.

A Google Play Console-ban a kezelt termékek (managed products) a Monetise → Products → In-app products szakaszban konfigurálhatók. A Google a Managed Product (a non-consumable megfelelője) és a Subscription kifejezéseket használja. Az Androidon történő consumable vásárlásokhoz külön consume jelzőt használnak, amely alaphelyzetbe állítja a terméket az újravásárláshoz.

Az IAP termékek moderációja átlagosan 24–48 órát vesz igénybe az App Store-ban és néhány órát a Google Play-ben. Az árváltoztatások azonnal életbe lépnek újbóli moderáció nélkül. A Product ID a létrehozás után nem módosítható — csak törölni és újra létrehozni lehet.

Server-side receipt validation és csalás elleni védelem

Receipt validation (a nyugta ellenőrzése) — az In-App Purchase feldolgozásának kötelező szakasza. A kliens alkalmazás elküldi a nyugtát (receipt) a saját szerverre, a szerver ellenőrzi az Apple (https://buy.itunes.apple.com) vagy a Google (https://androidpublisher.googleapis.com) API-ján keresztül, és csak sikeres validálás után utalja a terméket a felhasználónak.

Szerveroldali ellenőrzés nélkül a támadó meghamisíthatja a bolt válaszát és ingyen megkaphatja a terméket. A Client-side validation nem biztonságos, mert a felhasználó által ellenőrzött környezetben fut. A szerveroldali ellenőrzés garantálja, hogy a nyugta hiteles és a fizetés sikeresen megtörtént. Az Apple esetében az ellenőrzés a verifyReceipt végponton (production vagy sandbox) keresztül történik, a Google esetében az Android Publisher API-n keresztül. Mindkét bolt JSON formátumban ad vissza visszaigazolást.

Az Apple a nyugtában visszaadja a vásárlás adatait: product_id, transaction_id, purchase_date, expiration_date (előfizetések esetén). A Google hasonló mezőket ad vissza a Purchases.products.get vagy a Purchases.subscriptions.get API-n keresztül. A szervernek tárolnia kell az egyes nyugták transaction_id-ját, és el kell utasítania az azonos ID-val érkező ismételt kérelmeket a replay támadások elleni védelem érdekében.

IAP integrálása mobilalkalmazásba Swift és Kotlin nyelven

Integráció Az In-App Purchase platformkönyvtárak csatlakoztatását igényli: StoreKit 2 iOS-en és Billing Library 7+ Androidon. Az API-k lehetővé teszik a terméklista lekérését, a vásárlás kezdeményezését, az eredmény feldolgozását és a korábban megvásárolt termékek visszaállítását.

Swift — StoreKit 2 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) {
    // A nyugta megerősítve — a termék jóváírása
    await grantProduct(data.receipt.product_id)
}

A monetizáció legjobb gyakorlatai az In-App Purchase révén

Monetizáció Az In-App Purchase révén átgondolt árképzési stratégiát és UX-et igényel. A felhasználók hajlamosabbak az első vásárlásra, ha vonzó kezdőcsomagot (starter pack) kínálnak nekik alacsony áron. Az Apple és a Google javasolja a termék árának megjelenítését a vásárlás megerősítése előtt.

Subscription onboarding — a konverzió kritikus szakasza. Mutassa meg a felhasználónak az előfizetés értékét a fizetés kérése előtt: ingyenes próbaidőszak, díjcsomagok összehasonlítása, előnyök listája. Kutatások szerint az ingyenes próbaidőszak (free trial) 25–40%-kal növeli a fizető felhasználók konverzióját.

Restore Purchases kötelező a non-consumable termékek és előfizetések esetében. A visszaállítás gombjának elérhetőnek kell lennie az alkalmazás beállításaiban vagy a fizetési képernyőn. A Google és az Apple elutasíthatja az alkalmazást, ha a vásárlások visszaállítása nincs implementálva a megfelelő IAP típusokhoz.

Grace Period — türelmi időszak az előfizetésekhez, amely alatt a felhasználó megtartja a hozzáférést sikertelen fizetés után. Az iOS és az Android legfeljebb 30 napos grace period-ot támogat. A grace period bekapcsolása 10–15%-kal csökkenti a lemorzsolódási arányt (churn rate).

IAP árak A/B tesztelése — fontos monetizációs gyakorlat. Az App Store Connect támogatja a helyi árakat (Price Tiers) az ár módosításának lehetőségével a termék újbóli moderációja nélkül. A Google Play Console lehetővé teszi akár 5 különböző árazású alapcsomag konfigurálását egyetlen előfizetéses termékhez. Javasolt legalább két árpont tesztelése: a jelenlegi és az új. A tesztelést 2–4 héten keresztül kell végezni legalább 1000 felhasználós mintán árpontonként.

Bolt ellenőrzés és elutasítás kezelése — az IAP-t tartalmazó alkalmazás közzétételének kötelező szakasza. Az Apple különösen alaposan ellenőrzi az automatikusan megújuló előfizetéseket tartalmazó alkalmazásokat: meg kell adni egy tesztfiókot aktív előfizetéssel, meg kell jeleníteni az előfizetés lemondásának képernyőjét és implementálni kell a Restore Purchases-t. A Google Play kevésbé szigorú, de kéri a digitális tartalomhoz fűződő jogok megerősítését. Javasolt megjegyzést (Review Notes) hozzáadni az értékelő számára az IAP logika leírásával.