In-App Purchase — qué es, tipos de compras y cómo funciona la monetización

¿Qué es In-App Purchase?

In-App Purchase (IAP) es una tecnología que permite vender bienes y servicios digitales dentro de una aplicación móvil. Los pagos se procesan a través de App Store (en iOS) o Google Play (en Android), que cobran una comisión por procesar la transacción. El desarrollador recibe los fondos menos la comisión de la tienda.

Apple cobra una comisión del 30% (15% para pequeñas empresas con ingresos de hasta 1 millón de dólares). Google Play también cobra el 30% (15% sobre el primer millón de dólares de ingresos del desarrollador). Desde 2024, Google está probando el programa User Choice Billing, que permite a los desarrolladores utilizar sistemas de pago alternativos.

IAP es obligatorio para la venta de bienes digitales en aplicaciones según las políticas de App Store y Google Play. Los bienes físicos, servicios (transporte, entrega de comida) y pagos peer-to-peer pueden utilizar sistemas de pago de terceros.

Tipos de In-App Purchase: consumable, non-consumable y suscripción

App Store y Google Play admiten tres tipos principales de In-App Purchase. Cada tipo está diseñado para diferentes modelos de monetización. La elección del tipo de producto afecta la lógica de restauración de compras, la gestión de suscripciones y el comportamiento al reinstalar la aplicación.

Consumable (compras consumibles)

Los productos consumables son artículos que se pueden comprar varias veces y se consumen durante su uso. Ejemplos típicos: moneda del juego (monedas, gemas), vidas extra, potenciadores, mejoras consumibles. Los consumibles no se restauran al reinstalar la aplicación — el desarrollador gestiona el saldo de cada usuario en su propio servidor.

Non-Consumable (compras no consumibles)

Los productos no consumibles son artículos que se compran una vez y permanecen disponibles para siempre. Ejemplos: versión completa de la aplicación, niveles premium, desbloqueo de filtros, eliminación de publicidad. Los productos no consumibles se pueden restaurar mediante la API Restore Purchases: después de reinstalar, el usuario puede recuperar los artículos comprados anteriormente sin pagar de nuevo.

Auto-Renewable Subscription (suscripción con renovación automática)

La suscripción con renovación automática implica pagos recurrentes por acceso a contenido o servicio durante un período determinado (semana, mes, año). La suscripción se renueva automáticamente hasta que el usuario la cancela en la configuración de su cuenta. Las tiendas proporcionan notificaciones de servidor (App Store Server Notifications, Google Play Developer Notifications) sobre cambios en el estado de la suscripción: renovación, vencimiento, reembolso.

Configuración de IAP en App Store Connect y Google Play Console

La configuración de In-App Purchase comienza en los paneles de desarrollador: App Store Connect para iOS y Google Play Console para Android. Para cada producto, se especifica un ID de producto (Product ID), nombre, descripción, tipo y precio en dólares estadounidenses con conversión automática a monedas regionales. Tras su creación, el producto pasa por la moderación de la tienda.

En App Store Connect, los productos IAP se crean en la sección Features → In-App Purchases. Para cada producto, se selecciona un tipo (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) y se completan los nombres localizados. Para las suscripciones, se configuran adicionalmente los Grupos de Suscripción (Subscription Groups) — grupos de suscripciones intercambiables.

En Google Play Console, los productos gestionados se configuran en la sección Monetise → Products → In-app products. Google utiliza los términos Managed Product (análogo a non-consumable) y Subscription. Para compras consumibles en Android, se utiliza un indicador de consume independiente que restablece el producto para su recompra.

La moderación de productos IAP suele tardar 24–48 horas en App Store y unas horas en Google Play. Los cambios de precio se aplican inmediatamente sin necesidad de nueva moderación. Los ID de producto no se pueden modificar tras su creación — solo eliminarlos y crearlos de nuevo.

Validación de recibos del lado del servidor y protección contra fraudes

La validación de recibos es un paso obligatorio en el procesamiento de In-App Purchase. La aplicación cliente envía un recibo a su propio servidor, el servidor lo verifica a través de la API de Apple (https://buy.itunes.apple.com) o de Google (https://androidpublisher.googleapis.com), y solo después de una validación exitosa se entrega el producto al usuario.

Sin la validación del lado del servidor, un atacante podría falsificar la respuesta de la tienda y obtener el producto gratis. La validación del lado del cliente no es segura porque se ejecuta en un entorno controlado por el usuario. La validación del lado del servidor garantiza que el recibo es auténtico y que el pago se realizó correctamente. Para Apple, la verificación se realiza a través del endpoint verifyReceipt (producción o sandbox), para Google — a través de Android Publisher API. Ambas tiendas devuelven la confirmación en formato JSON.

Apple devuelve en el recibo los datos de la compra: product_id, transaction_id, purchase_date, expiration_date (para suscripciones). Google devuelve campos similares a través de las API Purchases.products.get o Purchases.subscriptions.get. El servidor debe almacenar el transaction_id de cada recibo y rechazar solicitudes duplicadas con el mismo ID para protegerse contra ataques de repetición.

Integración de IAP en una aplicación móvil con Swift y Kotlin

La integración de In-App Purchase requiere conectar las bibliotecas de la plataforma: StoreKit 2 en iOS y Billing Library 7+ en Android. Las API permiten solicitar una lista de productos, iniciar una compra, manejar el resultado y restaurar productos adquiridos anteriormente.

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

Validación de recibos del lado del 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 — entregando artículo
    await grantProduct(data.receipt.product_id)
}

Mejores prácticas de monetización mediante In-App Purchase

La monetización mediante In-App Purchase requiere una estrategia de precios y UX bien pensada. Los usuarios están más inclinados a realizar su primera compra si se les ofrece un paquete inicial atractivo a un precio bajo. Apple y Google recomiendan mostrar el precio del producto antes del momento de confirmación de la compra.

El onboarding de suscripción es una etapa crítica de conversión. Muestre al usuario el valor de la suscripción antes de solicitar el pago: un período de prueba gratuito, comparación de planes, lista de beneficios. Según las investigaciones, un período de prueba gratuito aumenta la conversión a usuarios de pago en un 25–40%.

Restore Purchases es obligatorio para productos no consumibles y suscripciones. El botón de restauración debe estar accesible en la configuración de la aplicación o en la pantalla de pago. Google y Apple pueden rechazar la aplicación si la restauración de compras no está implementada para los tipos de IAP correspondientes.

El período de gracia (Grace Period) es un período de aplazamiento para suscripciones durante el cual el usuario conserva el acceso tras un fallo de pago. iOS y Android admiten un período de gracia de hasta 30 días. Activar el período de gracia reduce la tasa de abandono (churn rate) en un 10–15%.

Las pruebas A/B de precios de IAP son una práctica importante de monetización. App Store Connect admite precios locales (Price Tiers) con la posibilidad de cambiar el precio sin necesidad de nueva moderación. Google Play Console permite configurar hasta 5 planes base con diferentes precios para un mismo producto de suscripción. Se recomienda probar al menos dos puntos de precio: el actual y el nuevo. Las pruebas deben realizarse durante 2–4 semanas con una muestra de al menos 1000 usuarios por punto de precio.

La revisión de la tienda y gestión de rechazos es una etapa obligatoria en la publicación de una aplicación con IAP. Apple revisa especialmente las aplicaciones con suscripciones de renovación automática: debe proporcionar una cuenta de prueba con una suscripción activa, mostrar la pantalla de cancelación de suscripción e implementar Restore Purchases. Google Play es menos estricto, pero requiere confirmación de los derechos de contenido digital. Se recomienda añadir una nota para el revisor (Review Notes) describiendo la lógica de IAP.