In-App Purchase — werking, aankooptypen en hoe monetisatie werkt

Wat is In-App Purchase?

In-App Purchase (IAP) — dit is een technologie waarmee digitale goederen en diensten binnen een mobiele app kunnen worden verkocht. Betalingen worden verwerkt via App Store (op iOS) of Google Play (op Android), die een commissie in rekening brengen voor de transactie. De ontwikkelaar ontvangt het bedrag minus de commissie van de winkel.

Apple brengt een commissie van 30% in rekening (15% voor kleine bedrijven met een omzet tot 1 miljoen dollar). Google Play brengt ook 30% in rekening (15% over de eerste 1 miljoen dollar aan ontwikkelaarsomzet). Sinds 2024 test Google het User Choice Billing-programma, waarmee ontwikkelaars alternatieve betaalsystemen kunnen gebruiken.

IAP is verplicht voor de verkoop van digitale goederen in apps volgens het beleid van App Store en Google Play. Fysieke goederen, diensten (taxirit, maaltijdbezorging) en peer-to-peer-betalingen kunnen gebruikmaken van externe betaalsystemen.

Typen In-App Purchase: consumable, non-consumable en subscription

App Store en Google Play ondersteunen drie hoofdtypen In-App Purchase. Elk type is bedoeld voor een ander monetisatiemodel. De keuze van het producttype beïnvloedt de logica voor het herstellen van aankopen, het beheer van abonnementen en het gedrag bij een herinstallatie van de app.

Consumable (verbruiksgoederen)

Consumable — dit zijn producten die herhaaldelijk kunnen worden gekocht en die verbruikt worden tijdens het gebruik. Typische voorbeelden: gamevaluta (munten, diamanten), extra levens, versnellers, verbruiksboosters. Consumable-producten worden niet hersteld bij een herinstallatie van de app — de ontwikkelaar beheert zelf het saldo van elke gebruiker op zijn eigen server.

Non-Consumable (niet-verbruiksproducten)

Non-Consumable — dit zijn producten die eenmalig worden gekocht en voor altijd beschikbaar blijven. Voorbeelden: volledige versie van de app, premium-levels, het ontgrendelen van filters, het verwijderen van advertenties. Non-consumable-producten worden hersteld via de Restore Purchases API: na een herinstallatie kan de gebruiker eerder gekochte producten terugkrijgen zonder opnieuw te betalen.

Auto-Renewable Subscription (automatisch verlengen)

Auto-Renewable Subscription — dit zijn terugkerende betalingen voor toegang tot content of een dienst voor een bepaalde periode (week, maand, jaar). Het abonnement wordt automatisch verlengd totdat de gebruiker het annuleert in de accountinstellingen. De winkels bieden servermeldingen (App Store Server Notifications, Google Play Developer Notifications) over wijzigingen in de abonnementsstatus: verlenging, vervaldatum, terugbetaling.

IAP instellen in App Store Connect en Google Play Console

Het instellen van In-App Purchase begint in de ontwikkelaarsportals: App Store Connect voor iOS en Google Play Console voor Android. Voor elk product worden een identificatie (Product ID), naam, beschrijving, type en prijs in Amerikaanse dollars met automatische conversie naar regionale valuta's opgegeven. Na het aanmaken doorloopt het product de moderatie van de winkel.

In App Store Connect worden IAP-producten aangemaakt in de sectie Features → In-App Purchases. Voor elk product wordt een type gekozen (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) en worden gelokaliseerde namen ingevuld. Voor abonnementen worden extra abonnementsgroepen (Subscription Groups) ingesteld — groepen van onderling uitwisselbare abonnementen.

In Google Play Console worden managed products ingesteld in de sectie Monetise → Products → In-app products. Google gebruikt de termen Managed Product (vergelijkbaar met non-consumable) en Subscription. Voor consumable-aankopen op Android wordt een aparte consume-vlag gebruikt die het product reset voor een nieuwe aankoop.

De moderatie van IAP-producten duurt gemiddeld 24–48 uur in de App Store en enkele uren in Google Play. Prijswijzigingen worden onmiddellijk toegepast zonder opnieuw te modereren. Het Product ID kan na het aanmaken niet worden gewijzigd — alleen verwijderen en opnieuw aanmaken.

Server-side receipt validation en bescherming tegen fraude

Receipt validation (controle van het aankoopbewijs) — een verplichte stap in de verwerking van In-App Purchase. De client-app stuurt het aankoopbewijs (receipt) naar de eigen server, de server controleert het via de API van Apple (https://buy.itunes.apple.com) of Google (https://androidpublisher.googleapis.com) en crediteert het product pas na succesvolle validatie.

Zonder servervalidatie kan een aanvaller het antwoord van de winkel vervalsen en het product gratis krijgen. Client-side validation is onveilig omdat deze wordt uitgevoerd in een omgeving die door de gebruiker wordt beheerd. De servercontrole garandeert dat het aankoopbewijs echt is en dat de betaling succesvol is verlopen. Voor Apple wordt de controle uitgevoerd via het verifyReceipt-endpoint (production of sandbox), voor Google via de Android Publisher API. Beide winkels retourneren een bevestiging in JSON-formaat.

Apple retourneert in het aankoopbewijs gegevens over de aankoop: product_id, transaction_id, purchase_date, expiration_date (voor abonnementen). Google retourneert vergelijkbare velden via de API Purchases.products.get of Purchases.subscriptions.get. De server moet het transaction_id van elk aankoopbewijs opslaan en herhaalde verzoeken met hetzelfde ID afwijzen ter bescherming tegen replay-aanvallen.

IAP integreren in een mobiele app met Swift en Kotlin

Integratie van In-App Purchase vereist het aansluiten van platformbibliotheken: StoreKit 2 op iOS en Billing Library 7+ op Android. Met de API's kun je de lijst met producten opvragen, een aankoop starten, het resultaat verwerken en eerder gekochte producten herstellen.

Swift — StoreKit 2 op 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) {
    // Ontvangstbewijs bevestigd — product crediteren
    await grantProduct(data.receipt.product_id)
}

Beste praktijken voor monetisatie via In-App Purchase

Monetisatie via In-App Purchase vereist een doordachte prijs- en UX-strategie. Gebruikers zijn sneller geneigd tot een eerste aankoop als hen een aantrekkelijk startpakket (starter pack) tegen een lage prijs wordt aangeboden. Apple en Google raden aan de productprijs te tonen vóór de bevestiging van de aankoop.

Subscription onboarding — een cruciale fase voor conversie. Toon de gebruiker de waarde van het abonnement vóór de betalingsaanvraag: gratis proefperiode, vergelijking van tarieven, lijst met voordelen. Volgens onderzoek verhoogt een gratis proefperiode (free trial) de conversie naar betalende gebruikers met 25–40%.

Restore Purchases is verplicht voor non-consumable-producten en abonnementen. De herstelknop moet beschikbaar zijn in de app-instellingen of op het betaalscherm. Google en Apple kunnen de app afwijzen als het herstellen van aankopen niet is geïmplementeerd voor de betreffende IAP-typen.

Grace Period — uitstelperiode voor abonnementen waarin de gebruiker toegang behoudt na een mislukte betaling. iOS en Android ondersteunen een grace period tot 30 dagen. Het inschakelen van de grace period verlaagt de churn (churn rate) met 10–15%.

A/B-testen van IAP-prijzen — een belangrijke monetisatiepraktijk. App Store Connect ondersteunt lokale prijzen (Price Tiers) waarbij de prijs kan worden gewijzigd zonder het product opnieuw te modereren. Google Play Console maakt het mogelijk om tot 5 basisplannen met verschillende prijzen in te stellen voor één abonnementproduct. Het wordt aanbevolen om minstens twee prijspunten te testen: het huidige en het nieuwe. Het testen duurt 2–4 weken op een steekproef van minstens 1000 gebruikers per prijspunt.

Store Review en afwijzingsbeheer — een verplichte fase bij de publicatie van een app met IAP. Apple controleert apps met auto-renewable subscriptions bijzonder grondig: je moet een testaccount met een actief abonnement verstrekken, het scherm voor het annuleren van het abonnement tonen en Restore Purchases implementeren. Google Play is minder streng, maar vraagt om bevestiging van de rechten op digitale content. Het wordt aanbevolen een opmerking voor de reviewer (Review Notes) toe te voegen met een beschrijving van de IAP-logica.