In-App Purchase — o que é, tipos de compras e como funciona a monetização

O que é In-App Purchase?

In-App Purchase (IAP) é uma tecnologia que permite vender bens e serviços digitais dentro de um aplicativo móvel. Os pagamentos são processados através da App Store (no iOS) ou do Google Play (no Android), que cobram uma comissão pelo processamento da transação. O desenvolvedor recebe os fundos menos a comissão da loja.

A Apple cobra uma comissão de 30% (15% para pequenas empresas com receita de até 1 milhão de dólares). O Google Play também cobra 30% (15% sobre o primeiro milhão de dólares de receita do desenvolvedor). Desde 2024, o Google está testando o programa User Choice Billing, que permite aos desenvolvedores usar sistemas de pagamento alternativos.

O IAP é obrigatório para a venda de bens digitais em aplicativos de acordo com as políticas da App Store e do Google Play. Bens físicos, serviços (transporte, entrega de comida) e pagamentos peer-to-peer podem usar sistemas de pagamento de terceiros.

Tipos de In-App Purchase: consumable, non-consumable e assinatura

A App Store e o Google Play suportam três tipos principais de In-App Purchase. Cada tipo é projetado para diferentes modelos de monetização. A escolha do tipo de produto afeta a lógica de restauração de compras, o gerenciamento de assinaturas e o comportamento ao reinstalar o aplicativo.

Consumable (compras consumíveis)

Os produtos consumíveis são itens que podem ser comprados várias vezes e são consumidos durante o uso. Exemplos típicos: moeda do jogo (moedas, gemas), vidas extras, impulsionadores, power-ups consumíveis. Os consumíveis não são restaurados ao reinstalar o aplicativo — o desenvolvedor gerencia o saldo de cada usuário em seu próprio servidor.

Non-Consumable (compras não consumíveis)

Os produtos não consumíveis são itens comprados uma vez e permanecem disponíveis para sempre. Exemplos: versão completa do aplicativo, níveis premium, desbloqueio de filtros, remoção de anúncios. Os produtos não consumíveis podem ser restaurados através da API Restore Purchases: após a reinstalação, o usuário pode recuperar itens comprados anteriormente sem pagar novamente.

Auto-Renewable Subscription (assinatura com renovação automática)

A assinatura com renovação automática envolve pagamentos recorrentes por acesso a conteúdo ou serviço por um período determinado (semana, mês, ano). A assinatura é renovada automaticamente até que o usuário a cancele nas configurações da conta. As lojas fornecem notificações de servidor (App Store Server Notifications, Google Play Developer Notifications) sobre mudanças no status da assinatura: renovação, expiração, reembolso.

Configuração de IAP no App Store Connect e Google Play Console

A configuração do In-App Purchase começa nos painéis do desenvolvedor: App Store Connect para iOS e Google Play Console para Android. Para cada produto, é especificado um ID de produto (Product ID), nome, descrição, tipo e preço em dólares americanos com conversão automática para moedas regionais. Após a criação, o produto passa pela moderação da loja.

No App Store Connect, os produtos IAP são criados na seção Features → In-App Purchases. Para cada produto, é selecionado um tipo (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) e os nomes localizados são preenchidos. Para assinaturas, os Grupos de Assinatura (Subscription Groups) são configurados adicionalmente — grupos de assinaturas intercambiáveis.

No Google Play Console, os produtos gerenciados são configurados na seção Monetise → Products → In-app products. O Google usa os termos Managed Product (análogo a non-consumable) e Subscription. Para compras consumíveis no Android, um sinalizador consume separado é usado, que redefine o produto para recompra.

A moderação de produtos IAP geralmente leva 24–48 horas na App Store e algumas horas no Google Play. As alterações de preço são aplicadas imediatamente sem nova moderação. Os IDs de produto não podem ser alterados após a criação — apenas excluídos e recriados.

Validação de recibos no servidor e proteção contra fraudes

A validação de recibos é uma etapa obrigatória no processamento do In-App Purchase. O aplicativo cliente envia um recibo para o seu servidor, o servidor o verifica através da API da Apple (https://buy.itunes.apple.com) ou do Google (https://androidpublisher.googleapis.com), e somente após a validação bem-sucedida o item é concedido ao usuário.

Sem a validação no servidor, um invasor pode falsificar a resposta da loja e obter o item gratuitamente. A validação no lado do cliente não é segura porque é executada em um ambiente controlado pelo usuário. A validação no servidor garante que o recibo é autêntico e que o pagamento foi bem-sucedido. Para a Apple, a verificação é feita através do endpoint verifyReceipt (produção ou sandbox), para o Google — através da Android Publisher API. Ambas as lojas retornam a confirmação em formato JSON.

A Apple retorna no recibo os dados da compra: product_id, transaction_id, purchase_date, expiration_date (para assinaturas). O Google retorna campos semelhantes através das APIs Purchases.products.get ou Purchases.subscriptions.get. O servidor deve armazenar o transaction_id de cada recibo e rejeitar solicitações duplicadas com o mesmo ID para proteção contra ataques de repetição.

Integração de IAP em um aplicativo móvel com Swift e Kotlin

A integração do In-App Purchase requer a conexão das bibliotecas da plataforma: StoreKit 2 no iOS e Billing Library 7+ no Android. As APIs permitem solicitar uma lista de produtos, iniciar uma compra, processar o resultado e restaurar itens adquiridos anteriormente.

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

Validação de recibos no servidor (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) {
    // Recibo confirmado — concedendo item
    await grantProduct(data.receipt.product_id)
}

Melhores práticas de monetização através de In-App Purchase

A monetização através de In-App Purchase requer uma estratégia de preços e UX bem pensada. Os usuários estão mais inclinados a fazer sua primeira compra se receberem um pacote inicial atraente a um preço baixo. A Apple e o Google recomendam mostrar o preço do produto antes da etapa de confirmação da compra.

O onboarding de assinatura é uma etapa crítica de conversão. Mostre ao usuário o valor da assinatura antes de solicitar o pagamento: um período de teste gratuito, comparação de planos, lista de benefícios. De acordo com pesquisas, um período de teste gratuito aumenta a conversão de usuários pagantes em 25–40%.

Restore Purchases é obrigatório para produtos não consumíveis e assinaturas. O botão de restauração deve estar acessível nas configurações do aplicativo ou na tela de pagamento. O Google e a Apple podem rejeitar o aplicativo se a restauração de compras não estiver implementada para os tipos de IAP relevantes.

O período de carência (Grace Period) é um período de diferimento para assinaturas durante o qual o usuário mantém o acesso após uma falha de pagamento. O iOS e o Android suportam um período de carência de até 30 dias. Ativar o período de carência reduz a taxa de rotatividade (churn rate) em 10–15%.

Os testes A/B de preços de IAP são uma prática importante de monetização. O App Store Connect suporta preços locais (Price Tiers) com a capacidade de alterar o preço sem nova moderação. O Google Play Console permite configurar até 5 planos base com preços diferentes para um único produto de assinatura. Recomenda-se testar pelo menos dois pontos de preço: o atual e o novo. O teste deve ser realizado por 2–4 semanas em uma amostra de pelo menos 1000 usuários por ponto de preço.

A revisão da loja e gestão de rejeições é uma etapa obrigatória na publicação de um aplicativo com IAP. A Apple examina especialmente aplicativos com assinaturas de renovação automática: você deve fornecer uma conta de teste com uma assinatura ativa, mostrar a tela de cancelamento de assinatura e implementar Restore Purchases. O Google Play é menos rigoroso, mas exige confirmação dos direitos de conteúdo digital. Recomenda-se adicionar uma nota para o revisor (Review Notes) descrevendo a lógica do IAP.