Покупки в приложението — същност, видове покупки и как работи монетизацията

Какво е 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 и subscription

App Store и Google Play поддържат три основни вида In-App Purchase. Всеки вид е предназначен за различни модели на монетизация. Изборът на вид продукт влияе върху логиката за възстановяване на покупки, управлението на абонаменти и поведението при преинсталиране на приложението.

Consumable (консумативни покупки)

Consumable — са стоки, които могат да се закупуват многократно и се изразходват по време на употреба. Типични примери: игрова валута (монети, диаманти), допълнителни животи, ускорители, консумативни бустери. Consumable не се възстановяват при преинсталиране на приложението — разработчикът сам управлява баланса на всеки потребител на своя сървър.

Non-Consumable (неконсумативни покупки)

Non-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 управляваните продукти (managed products) се конфигурират в секция Monetise → Products → In-app products. Google използва термините Managed Product (аналог на non-consumable) и Subscription. За consumable покупки на Android се използва отделен флаг consume, който нулира продукта за повторно закупуване.

Модерацията на IAP продукти отнема средно 24–48 часа в App Store и няколко часа в Google Play. Промените в цените се прилагат незабавно без повторна модерация. Product ID не може да се променя след създаване — може само да се изтрие и създаде наново.

Server-side receipt validation и защита от измами

Receipt validation (проверка на разписка) — задължителен етап от обработката на In-App Purchase. Клиентското приложение изпраща разписка (receipt) на собствения сървър, сървърът я проверява чрез API на Apple (https://buy.itunes.apple.com) или Google (https://androidpublisher.googleapis.com) и едва след успешно валидиране зачислява продукта на потребителя.

Без сървърно валидиране нападателят може да фалшифицира отговора на магазина и да получи продукта безплатно. Client-side validation е несигурна, тъй като се изпълнява в среда, контролирана от потребителя. Сървърната проверка гарантира, че разписката е автентична и плащането е преминало успешно. За Apple проверката се извършва чрез крайната точка verifyReceipt (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)

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) {
    // Разписката е потвърдена — зачисляваме продукта
    await grantProduct(data.receipt.product_id)
}

Най-добри практики за монетизация чрез In-App Purchase

Монетизацията чрез In-App Purchase изисква добре обмислена ценова стратегия и UX. Потребителите са по-склонни към първа покупка, ако им се предложи атрактивен начален пакет (starter pack) на ниска цена. Apple и Google препоръчват показване на цената на продукта преди потвърждаване на покупката.

Subscription onboarding — критичен етап на конверсия. Покажете на потребителя стойността на абонамента преди да поискате плащане: безплатен пробен период, сравнение на тарифи, списък с предимства. Според проучвания безплатният пробен период (free trial) увеличава конверсията на плащащите потребители с 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 базови плана с различни цени за един абонаментен продукт. Препоръчва се тестване на поне две ценови точки: текущата и новата. Тестването се провежда в продължение на 2–4 седмици на извадка от поне 1000 потребители за всяка ценова точка.

Преглед на магазина и управление на отхвърляне — задължителен етап при публикуване на приложение с IAP. Apple проверява особено внимателно приложения с абонаменти с автоматично подновяване: трябва да предоставите тестов акаунт с активен абонамент, да покажете екрана за анулиране на абонамента и да имплементирате Restore Purchases. Google Play е по-малко строг, но изисква потвърждение на правата върху цифрово съдържание. Препоръчва се добавяне на бележка за рецензента (Review Notes) с описание на логиката на IAP.