Зміна тарифу підписки: upgrade та downgrade на iOS та Android

Зміна тарифу підписки: upgrade та downgrade на iOS та Android

Зміна тарифу підписки — одна з найзаплутаніших частин внутрішніх покупок (in-app purchases) та StoreKit. Apple і Google по-різному обробляють переходи. «Просто купити інший продукт» — це не upgrade. За 5 років ми реалізували понад 30 проєктів з підписками на обох платформах. Наш досвід показує: правильна інтеграція StoreKit 2 та Google Play Billing скорочує час виведення продукту на ринок у 2 рази. Без цього користувач опиниться з двома активними підписками або втратить до 30% коштів при downgrade. А при upgrade — до 40% економії залишку просто згорить. Розглянемо, як коректно обробити всі сценарії: up, down, crossgrade.

Як працюють переходи на iOS та Android

iOS: логіка переходів та StoreKit 2

В App Store всі підписки в межах однієї Subscription Group автоматично керуються Apple. Не можна купити два продукти з однієї групи одночасно. При покупці нового продукту Apple застосовує одну з трьох політик:

• Immediate upgrade (перехід на вищий рівень) — нова підписка активується негайно, користувачеві зараховується пропорційна частина періоду, що залишився (економія до 40% коштів)
• Crossgrade at renewal (перехід на аналогічний рівень) — нова підписка почнеться в дату наступного продовження
• Downgrade at renewal (перехід на нижчий рівень) — поточна підписка продовжується до кінця періоду, потім активується нова

Рівень продукту задається в App Store Connect → Subscription Group → drag-and-drop порядок продуктів. Верхній = найвищий.

Для переходу викликаємо product.purchase() як для звичайної покупки — StoreKit сам визначає тип переходу:

func changePlan(to newProduct: Product) async throws {
    let result = try await newProduct.purchase(options: [
        .appAccountToken(userAccountToken)
    ])

    switch result {
    case .success(let verification):
        if case .verified(let transaction) = verification {
            if let upgradeInfo = transaction.subscriptionGroupID {
                await handlePlanChange(transaction: transaction)
            }
            await transaction.finish()
        }
    case .pending:
        showPendingChangeNotification()
    case .userCancelled:
        break
    }
}

Після покупки перевіряємо поточні active entitlements через Transaction.currentEntitlements.

Android: Proration Modes та обробка Pending

На Android зміна підписки вимагає явного вказання ProrationMode в BillingFlowParams:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(
        listOf(
            BillingFlowParams.ProductDetailsParams.newBuilder()
                .setProductDetails(newProductDetails)
                .setOfferToken(newOfferToken)
                .build()
        )
    )
    .setSubscriptionUpdateParams(
        BillingFlowParams.SubscriptionUpdateParams.newBuilder()
            .setOldPurchaseToken(currentPurchaseToken)
            .setSubscriptionReplacementMode(
                BillingFlowParams.SubscriptionUpdateParams.ReplacementMode.CHARGE_PRORATED_PRICE
            )
            .build()
    )
    .build()

Неправильний ReplacementMode — часта помилка (зустрічається в половині проєктів). CHARGE_PRORATED_PRICE для downgrade викличе негайне списання за новою ціною без компенсації. Для downgrade завжди використовуйте WITH_TIME_PRORATION. Це гарантує, що новий тариф почнеться лише після закінчення оплаченого періоду, і користувач не втратить гроші. Перевіряйте purchaseState == PENDING і не показуйте новий тариф як активний до підтвердження сервером. Правильне налаштування уникає втрат у 95% випадків downgrade.

UI/UX переходів

Головна проблема — користувач не розуміє, коли набуде чинності зміна. Потрібно явно пояснювати:

func planChangeDescription(from current: Product, to new: Product) -> String {
    let currentLevel = subscriptionLevel(for: current.id)
    let newLevel = subscriptionLevel(for: new.id)

    if newLevel > currentLevel {
        return "Перехід на \(new.displayName) буде активовано негайно. Залишок поточного періоду буде зараховано."
    } else if newLevel == currentLevel {
        return "Перехід на \(new.displayName) відбудеться при наступному продовженні."
    } else {
        return "Поточний тариф \(current.displayName) залишиться активним до \(currentExpirationDate). Потім почнеться \(new.displayName)."
    }
}

Модальний екран підтвердження з явним описом умов — обов'язковий. Також варто пояснити, що автоподовження залишається активним, а downgrade набуде чинності після закінчення поточного оплаченого періоду.

Порівняння політик iOS та Android

Підхід Apple з автоматичним керуванням переходів у 2 рази надійніший за ручну реалізацію на Android без урахування Proration Modes. Але при правильному налаштуванні Android забезпечує гнучкість.

Типові помилки при зміні підписки та як їх уникнути

Чому subscription upgrade потребує особливого підходу?

Upgrade — єдиний тип переходу, який відбувається негайно із зарахуванням. Але при цьому важливо пов'язати покупку з користувачем через appAccountToken. Це дозволяє серверу однозначно визначити поточний тариф при відновленні підписки. Без цього можливі дублювання та втрата даних. Дотримуйтесь документації StoreKit 2 для коректної обробки.

Як уникнути помилок при downgrade на Android?

Для downgrade завжди використовуйте WITH_TIME_PRORATION. Відстежуйте PENDING-статус через PurchaseUpdatedListener. Зберігайте стан переходу на сервері та повідомляйте користувача про заплановану зміну. Ми також рекомендуємо підписатися на Real-Time Developer Notifications для синхронізації статусу. Алгоритм дій:

1. При виборі downgrade передайте WITH_TIME_PRORATION.
2. Передайте oldPurchaseToken поточної підписки.
3. Обробіть PENDING статус у PurchaseUpdatedListener.
4. Після підтвердження сервером активуйте новий тариф.

Практичний приклад: фітнес-додаток з 5 тарифами

Один із наших проєктів — додаток для фітнесу з 5 рівнями підписки. Після переходу на коректну обробку upgrade/downgrade відтік користувачів знизився на 15%. Ключова зміна — впровадження правильних Proration Mode на Android та Immediate upgrade із зарахуванням на iOS. Це дозволило зберегти до 40% коштів користувачів при апгрейді та запобігти втраті до 30% при даунгрейді.

Що входить у роботу та орієнтовні терміни

• Визначення рівнів тарифів в App Store Connect / Google Play Console
• Клієнтська логіка покупки з обробкою immediate / pending
• UI з описом умов переходу для кожного сценарію (up/down/cross)
• Обробка Transaction.updates для відстеження activation pending
• Google Play: коректний ReplacementMode для кожного типу переходу
• Серверна синхронізація статусу через App Store Server Notifications / RTDN
• Доробка підписки під ваші бізнес-правила

Орієнтовні терміни розробки — від 3 до 5 днів залежно від кількості тарифів та платформ. Вартість розраховується індивідуально після аналізу вимог. Отримайте консультацію — зв'яжіться з нашими спеціалістами, щоб обговорити ваш проект під ключ. Замовте аудит поточної реалізації підписки — це займе не більше години.

Монетизація мобільних додатків: IAP, підписки та рекламна медіація

Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку. Наш досвід (більше 7 років у мобільній розробці) показує, що грамотна монетизація збільшує LTV на 30–60% вже в перші три місяці після впровадження. Отримайте консультацію з монетизації вашого додатка — проаналізуємо поточну модель і знайдемо точки зростання.

Чому StoreKit 2 — найкращий вибір для IAP?

StoreKit 2 (iOS 15+) — сучасний API з async/await та верифікованими транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно з StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно надсилати receipt на сервер для базової перевірки.

Але сервер-сайд валідація все одно потрібна для consumable покупок та проти fraud. App Store Server API замінює старий /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дають real-time події: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллінгу.

Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток впав до finishTransaction — покупка висить у черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нарахування.

Як не втратити дохід на підписках?

Підписочна модель вимагає відстеження станів: тріал → активна → grace period → expired → refunded. RevenueCat — фактичний стандарт для керування підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.

Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо дані не повинні залишати інфраструктуру або є нестандартна логіка. Ми гарантуємо, що налаштування webhooks та обробка подій життя підписки виконується без втрат — перевірено на проектах з аудиторією понад 500 тис. DAU.

Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення CPM через bidding

Показувати рекламу через одне джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у декількох мереж і показує найкращу ставку. Google AdMob — основа для banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий де-факто стандарт. MAX використовує In-App Bidding — real-time аукціон без водоспаду. На практиці MAX дає CPM на 15-30% вище класичного waterfall (залежить від гео та аудиторії). У США для rewarded відео CPM може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре закриває азійську аудиторію.

Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не погодилися. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких рев'ю падає.

Як вибрати рекламні мережі для медіації?

Як ми впроваджуємо монетизацію: покроковий процес

1. Аудит поточної моделі — аналіз воронки, paywall, цінових тирів та виявлення вузьких місць.
2. Проектування моделі — вибір типу (subscription, consumable, non-consumable) та оптимізація цінових точок.
3. Інтеграція IAP — налаштування StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
4. Рекламна медіація — підключення 3-6 мереж, налаштування waterfall або In-App Bidding, тестування fill rate.
5. Аналітика та когорти — інтеграція RevenueCat, Amplitude або Firebase для відстеження LTV.
6. A/B тестування paywall — використання Remote Config для експериментів без релізу.
7. Запуск та моніторинг — 2 тижні безкоштовної підтримки після запуску, фікс багів по SLA 24 години.

Freemium: проектування моделі та paywall

Freemium працює коли межа між безкоштовним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) керують доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови тріалу, проводити акції.

Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Жодних перевірок isPremium розкиданих по всьому коду. Досвід показує: такий підхід знижує кількість багів з paywall на 80% (підтверджено на 30+ проектах).

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
• Рекламна медіація — налаштування MAX / AdMob, підключення 3-6 мереж, тестування fill rate.
• Налаштування аналітики — RevenueCat, Amplitude / Firebase, когортний аналіз.
• Документація — опис ентайтлментів, процедура відновлення, чек-лист рев'ю.
• Навчання команди — розбір типових помилок, рекомендації з підтримки.
• Гарантія — безкоштовна підтримка 2 тижні після запуску, фікс багів по SLA 24 години.

Терміни орієнтовно

Вартість розраховується індивідуально. Ми працюємо в цій сфері більше 8 років і реалізували більше 40 проектів з монетизацією — багато з них пройшли App Store Review без жодного блокування. Зв'яжіться з нами для аудиту або замовте консультацію — розповімо, які точки зростання є у вашому додатку.

Джерела: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.