In-App Purchase — що це, типи покупок і як працює монетизація

Що таке In-App Purchase?

In-App Purchase (IAP) — це технологія, яка дозволяє продавати цифрові товари та послуги всередині мобільного застосунку. Платежі обробляються через App Store (на iOS) або Google Play (на Android), які стягують комісію за проведення транзакції. Розробник отримує кошти за вирахуванням комісії магазину.

Apple стягує комісію 30% (15% для малого бізнесу з доходом до 1 мільйона доларів). Google Play також стягує 30% (15% на перший 1 мільйон доларів доходу розробника). З 2024 року Google тестує програму User Choice Billing, яка дозволяє розробникам використовувати альтернативні платіжні системи.

IAP обов'язковий для продажу цифрових товарів у застосунках згідно з політиками App Store і Google Play. Фізичні товари, послуги (замовлення таксі, доставка їжі) та peer-to-peer платежі можуть використовувати сторонні платіжні системи.

Типи In-App Purchase: consumable, non-consumable і підписка

App Store і Google Play підтримують три основних типи In-App Purchase. Кожен тип призначений для різних моделей монетизації. Вибір типу продукту впливає на логіку відновлення покупок, управління підписками та поведінку при повторному встановленні застосунку.

Consumable (витратні покупки)

Витратні покупки — це товари, які можна придбавати багаторазово і які витрачаються в процесі використання. Типові приклади: ігрова валюта (монети, діаманти), додаткові життя, прискорювачі, витратні бустери. Витратні покупки не відновлюються при перевстановленні застосунку — розробник сам керує балансом кожного користувача на своєму сервері.

Non-Consumable (невитратні покупки)

Невитратні покупки — це товари, які купуються один раз і залишаються доступними назавжди. Приклади: повна версія застосунку, преміум-рівні, розблокування фільтрів, видалення реклами. Невитратні продукти відновлюються через Restore Purchases API: після перевстановлення користувач може повернути раніше куплені товари без повторної оплати.

Auto-Renewable Subscription (автопродовження)

Auto-Renewable Subscription — це регулярні платежі за доступ до контенту чи сервісу на певний період (тиждень, місяць, рік). Підписка автоматично продовжується, доки користувач не скасує її в налаштуваннях облікового запису. Магазини надають серверні сповіщення (App Store Server Notifications, Google Play Developer Notifications) про зміну статусу підписки: продовження, закінчення, повернення.

Налаштування IAP в App Store Connect і Google Play Console

Налаштування In-App Purchase починається в панелях розробника: App Store Connect для iOS і Google Play Console для Android. Для кожного продукту вказується ідентифікатор (Product ID), назва, опис, тип і ціна в доларах США з автоматичною конвертацією в регіональні валюти. Після створення продукт проходить модерацію магазину.

В App Store Connect продукти IAP створюються в розділі Features → In-App Purchases. Для кожного продукту вибирається тип (consumable, non-consumable, auto-renewable subscription, non-renewing subscription) і заповнюються локалізовані назви. Для підписок додатково налаштовуються групи підписок (Subscription Groups) — групи взаємозамінних підписок.

В Google Play Console керовані продукти налаштовуються в розділі Monetise → Products → In-app products. Google використовує терміни Managed Product (аналог non-consumable) і Subscription. Для витратних покупок на Android використовується окремий прапорець consume, який скидає продукт для повторної покупки.

Модерація IAP-продуктів у середньому займає 24–48 годин в App Store і кілька годин в Google Play. Зміни цін застосовуються негайно без повторної модерації. Product ID не можна змінити після створення — тільки видалити і створити заново.

Перевірка чека на сервері та захист від фроду

Перевірка чека — обов'язковий етап обробки In-App Purchase. Клієнтський застосунок надсилає чек на власний сервер, сервер перевіряє його через API Apple (https://buy.itunes.apple.com) або Google (https://androidpublisher.googleapis.com) і тільки після успішної валідації зараховує товар користувачеві.

Без серверної валідації зловмисник може підмінити відповідь від магазину та отримати товар безкоштовно. Клієнтська валідація небезпечна, оскільки виконується в середовищі, контрольованому користувачем. Серверна перевірка гарантує, що чек справжній і оплата пройшла успішно. Для Apple перевірка виконується через verifyReceipt endpoint (production або sandbox), для Google — через Android Publisher API. Обидва магазини повертають підтвердження у форматі JSON.

Apple повертає в чеку дані про покупку: product_id, transaction_id, purchase_date, expiration_date (для підписок). Google повертає аналогічні поля через API Purchases.products.get або Purchases.subscriptions.get. Сервер повинен зберігати transaction_id кожного чека та відхиляти повторні запити з тим же ID для захисту від replay-атак.

Інтеграція IAP у мобільний застосунок на Swift і Kotlin

Інтеграція In-App Purchase вимагає підключення платформових бібліотек: StoreKit 2 на iOS і Billing Library 7+ на Android. API дозволяють запитувати список продуктів, ініціювати покупку, обробляти результат і відновлювати раніше придбані товари.

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)

Перевірка чека на сервері (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) {
    // Чек підтверджено — зараховуємо товар
    await grantProduct(data.receipt.product_id)
}

Найкращі практики монетизації через In-App Purchase

Монетизація через In-App Purchase потребує продуманої стратегії ціноутворення та UX. Користувачі більш схильні до першої покупки, якщо їм пропонується привабливий початковий пакет (starter pack) за низькою ціною. Apple і Google рекомендують показувати ціну продукту до моменту підтвердження покупки.

Subscription onboarding — критичний етап конверсії. Покажіть користувачеві цінність підписки до запиту оплати: безкоштовний пробний період, порівняння тарифів, список переваг. За даними досліджень, безкоштовний пробний період збільшує конверсію в платячих користувачів на 25–40%.

Restore Purchases обов'язковий для non-consumable продуктів і підписок. Кнопка відновлення має бути доступна в налаштуваннях застосунку або на екрані оплати. Google і Apple можуть відхилити застосунок, якщо відновлення покупок не реалізовано для відповідних типів IAP.

Grace Period — період відстрочки для підписок, протягом якого користувач зберігає доступ після збою оплати. iOS і Android підтримують grace period до 30 днів. Увімкнення grace period знижує відтік (churn rate) на 10–15%.

A/B-тестування цін IAP — важлива практика монетизації. App Store Connect підтримує локальні ціни (Price Tiers) з можливістю змінювати ціну без повторної модерації продукту. Google Play Console дозволяє налаштовувати до 5 базових планів з різними цінами для одного subscription product. Рекомендується тестувати не менше двох цінових точок: поточну та нову. Тестування проводиться протягом 2–4 тижнів на вибірці не менше 1000 користувачів на кожну цінову точку.

Store Review і Rejection-менеджмент — обов'язковий етап публікації застосунку з IAP. Apple особливо ретельно перевіряє застосунки з auto-renewable subscriptions: необхідно надати тестовий обліковий запис з активною підпискою, показати екран скасування підписки та реалізувати Restore Purchases. Google Play менш суворий, але запитує підтвердження прав на цифровий контент. Рекомендується додати примітку для рецензента (Review Notes) з описом логіки IAP.