In-App Purchase — cos'è, tipi di acquisti e come funziona la monetizzazione

Cos'è l'In-App Purchase?

L'In-App Purchase (IAP) è una tecnologia che consente di vendere beni e servizi digitali all'interno di un'applicazione mobile. I pagamenti vengono elaborati tramite l'App Store (su iOS) o Google Play (su Android), che applicano una commissione per l'elaborazione della transazione. Lo sviluppatore riceve i fondi meno la commissione del negozio.

Apple applica una commissione del 30% (15% per le piccole imprese con un fatturato fino a 1 milione di dollari). Google Play applica anch'esso il 30% (15% sul primo milione di dollari di fatturato dello sviluppatore). Dal 2024, Google sta testando il programma User Choice Billing, che consente agli sviluppatori di utilizzare sistemi di pagamento alternativi.

L'IAP è obbligatorio per la vendita di beni digitali nelle app secondo le politiche dell'App Store e di Google Play. I beni fisici, i servizi (taxi, consegna cibo) e i pagamenti peer-to-peer possono utilizzare sistemi di pagamento di terze parti.

Tipi di In-App Purchase: consumable, non-consumable e abbonamento

L'App Store e Google Play supportano tre tipi principali di In-App Purchase. Ogni tipo è progettato per diversi modelli di monetizzazione. La scelta del tipo di prodotto influisce sulla logica di ripristino degli acquisti, sulla gestione degli abbonamenti e sul comportamento in caso di reinstallazione dell'app.

Consumable (acquisti consumabili)

Gli acquisti consumabili sono articoli che possono essere acquistati più volte e vengono consumati durante l'uso. Esempi tipici: valuta di gioco (monete, gemme), vite extra, potenziatori, power-up consumabili. I consumabili non vengono ripristinati in caso di reinstallazione dell'app — lo sviluppatore gestisce il saldo di ogni utente sul proprio server.

Non-Consumable (acquisti non consumabili)

Gli acquisti non consumabili sono articoli acquistati una volta e rimangono disponibili per sempre. Esempi: versione completa dell'app, livelli premium, sblocco di filtri, rimozione pubblicità. I prodotti non consumabili possono essere ripristinati tramite l'API Restore Purchases: dopo la reinstallazione, l'utente può recuperare gli articoli acquistati in precedenza senza pagare di nuovo.

Auto-Renewable Subscription (abbonamento con rinnovo automatico)

L'abbonamento con rinnovo automatico prevede pagamenti ricorrenti per l'accesso a contenuti o servizi per un periodo determinato (settimana, mese, anno). L'abbonamento si rinnova automaticamente finché l'utente non lo annulla nelle impostazioni dell'account. I negozi forniscono notifiche server (App Store Server Notifications, Google Play Developer Notifications) sulle modifiche dello stato dell'abbonamento: rinnovo, scadenza, rimborso.

Configurazione di IAP in App Store Connect e Google Play Console

La configurazione dell'In-App Purchase inizia nei pannelli sviluppatore: App Store Connect per iOS e Google Play Console per Android. Per ogni prodotto, si specifica un ID prodotto (Product ID), nome, descrizione, tipo e prezzo in dollari USA con conversione automatica nelle valute regionali. Dopo la creazione, il prodotto viene sottoposto alla moderazione del negozio.

In App Store Connect, i prodotti IAP vengono creati nella sezione Features → In-App Purchases. Per ogni prodotto, si seleziona un tipo (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) e si compilano i nomi localizzati. Per gli abbonamenti, vengono inoltre configurati i Gruppi di abbonamento (Subscription Groups) — gruppi di abbonamenti intercambiabili.

In Google Play Console, i prodotti gestiti vengono configurati nella sezione Monetise → Products → In-app products. Google utilizza i termini Managed Product (analogo a non-consumable) e Subscription. Per gli acquisti consumabili su Android, viene utilizzato un flag consume separato che reimposta il prodotto per un riacquisto.

La moderazione dei prodotti IAP richiede solitamente 24–48 ore nell'App Store e poche ore in Google Play. Le modifiche di prezzo vengono applicate immediatamente senza nuova moderazione. Gli ID prodotto non possono essere modificati dopo la creazione — solo eliminati e ricreati.

Validazione delle ricevute lato server e protezione dalle frodi

La validazione delle ricevute è un passaggio obbligatorio nell'elaborazione dell'In-App Purchase. L'applicazione client invia una ricevuta al proprio server, il server la verifica tramite l'API di Apple (https://buy.itunes.apple.com) o di Google (https://androidpublisher.googleapis.com), e solo dopo una validazione riuscita concede l'articolo all'utente.

Senza validazione lato server, un malintenzionato potrebbe falsificare la risposta del negozio e ottenere l'articolo gratuitamente. La validazione lato client non è sicura perché viene eseguita in un ambiente controllato dall'utente. La validazione lato server garantisce che la ricevuta sia autentica e che il pagamento sia avvenuto con successo. Per Apple, la verifica viene effettuata tramite l'endpoint verifyReceipt (produzione o sandbox), per Google — tramite l'Android Publisher API. Entrambi i negozi restituiscono la conferma in formato JSON.

Apple restituisce nella ricevuta i dati di acquisto: product_id, transaction_id, purchase_date, expiration_date (per gli abbonamenti). Google restituisce campi simili tramite le API Purchases.products.get o Purchases.subscriptions.get. Il server deve memorizzare il transaction_id di ogni ricevuta e rifiutare richieste duplicate con lo stesso ID per proteggersi dagli attacchi di replay.

Integrazione di IAP in un'app mobile con Swift e Kotlin

L'integrazione dell'In-App Purchase richiede il collegamento delle librerie di piattaforma: StoreKit 2 su iOS e Billing Library 7+ su Android. Le API consentono di richiedere un elenco di prodotti, avviare un acquisto, gestire il risultato e ripristinare gli articoli acquistati in precedenza.

Swift — StoreKit 2 su 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)

Validazione delle ricevute lato server (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) {
    // Ricevuta confermata — articolo in consegna
    await grantProduct(data.receipt.product_id)
}

Migliori pratiche di monetizzazione tramite In-App Purchase

La monetizzazione tramite In-App Purchase richiede una strategia di prezzo e un'UX ben ponderati. Gli utenti sono più propensi a effettuare il primo acquisto se viene offerto un pacchetto iniziale interessante a un prezzo basso. Apple e Google raccomandano di mostrare il prezzo del prodotto prima della fase di conferma dell'acquisto.

L'onboarding dell'abbonamento è una fase critica di conversione. Mostra all'utente il valore dell'abbonamento prima di richiedere il pagamento: un periodo di prova gratuito, il confronto dei piani, un elenco di vantaggi. Secondo le ricerche, un periodo di prova gratuito aumenta la conversione in utenti paganti del 25–40%.

Restore Purchases è obbligatorio per i prodotti non consumabili e gli abbonamenti. Il pulsante di ripristino deve essere accessibile nelle impostazioni dell'app o nella schermata di pagamento. Google e Apple potrebbero rifiutare l'app se il ripristino degli acquisti non è implementato per i tipi di IAP pertinenti.

Il periodo di grazia (Grace Period) è un periodo di differimento per gli abbonamenti durante il quale l'utente mantiene l'accesso dopo un pagamento fallito. iOS e Android supportano un periodo di grazia fino a 30 giorni. L'attivazione del periodo di grazia riduce il tasso di abbandono (churn rate) del 10–15%.

Il test A/B dei prezzi IAP è una pratica importante di monetizzazione. App Store Connect supporta i prezzi locali (Price Tiers) con la possibilità di modificare il prezzo senza nuova moderazione. Google Play Console consente di configurare fino a 5 piani base con prezzi diversi per un unico prodotto in abbonamento. Si consiglia di testare almeno due punti di prezzo: quello attuale e quello nuovo. Il test dovrebbe essere condotto per 2–4 settimane su un campione di almeno 1000 utenti per punto di prezzo.

La revisione del negozio e la gestione dei rifiuti è una fase obbligatoria nella pubblicazione di un'app con IAP. Apple esamina particolarmente le app con abbonamenti a rinnovo automatico: è necessario fornire un account di prova con un abbonamento attivo, mostrare la schermata di annullamento dell'abbonamento e implementare Restore Purchases. Google Play è meno severo ma richiede la conferma dei diritti sui contenuti digitali. Si consiglia di aggiungere una nota per il revisore (Review Notes) che descriva la logica IAP.