Інтеграція In-App Purchases у Unity: IAP, підписки, валідація

Інтеграція внутрішньоігрових покупок (In-app purchases)

Ми часто бачимо проєкти, де Unity IAP підключили за годину — і наступного дня отримують InitializationFailureReason.PurchasingUnavailable у продакшені на iOS 17. Розбираєшся — виявляється, entitlement для In-App Purchase в App Store Connect не налаштовано, а sandbox-тестер не додано. І це тільки вершина айсберга.

IAP-інтеграція — це зв'язка між клієнтом, платіжною системою магазину та бекендом, яка повинна працювати коректно при нестабільному інтернеті, перерваних транзакціях і спробах шахрайства. Помилки тут коштують грошей: середня втрата від однієї необробленої транзакції — 200 грн, а chargeback може обійтися видавцю в 500 тис. грн.

Які проблеми виникають при інтеграції IAP?

Pending-транзакції. Користувач натиснув «Купити», гроші списалися, з'єднання обірвалося — ProcessPurchase не викликався. Unity IAP зберігає транзакцію в чергу і при наступному запуску спробує її завершити. Але якщо бекенд не реалізує idempotency за transactionID, гравець отримає товар двічі або не отримає взагалі. Бачили проєкти, де PendingOrderResponse накопичувався тижнями через відсутній ConfirmPendingPurchase() у потрібному місці.

Receipt validation. Без серверної валідації квитанцій гра вразлива до фродових покупок через модифіковані APK або jailbroken-пристрої. Apple повертає base64-encoded receipt у Product.receipt, Google — JSON із підписом. Локальна перевірка через UnityEngine.Purchasing.Security.CrossPlatformValidator — мінімальний бар'єр, але недостатній. Повноцінна валідація: надсилання квитанції на свій сервер, перевірка через Apple App Store Server API (/verifyReceipt або новий StoreKit 2 JWS-токен) чи Google Play Developer API (purchases.products.get). Статистика: серверна валідація знижує кількість chargeback на 95%.

Restore Purchases на iOS. Apple вимагає кнопку відновлення покупок для non-consumable та subscriptions — без неї застосунок не пройде рев'ю. IAppleExtensions.RestoreTransactions() має бути доступний з UI, а обробник OnTransactionsRestored — коректно оновлювати стан інвентарю без дублів.

Окрема біль — підписки. SubscriptionManager в Unity IAP вміє парсити дату закінчення та статус renewal, але тільки за наявності валідного receipt. На Android з Google Play Billing Library 5+ потрібно явно запитувати queryPurchasesAsync при кожному старті — кеш застаріває. Вчасно не оновили — користувач залишається з доступом до платного контенту безкоштовно.

Чому важлива серверна валідація?

Згідно з документацією Apple StoreKit, серверна валідація виключає підробку receipt на пристрої. Порівняємо два підходи:

Серверна валідація на 40% надійніша за локальну та знижує ризик chargeback до мінімуму. Без неї великі видавці не випускають ігри. Економія від серверної валідації: до 30% коштів, які інакше пішли б на chargeback.

Як ми це робимо: стек та підхід

Починаємо з аудиту поточного стану: чи є бекенд, чи потрібна серверна валідація, яка монетизаційна модель (consumable, non-consumable, subscriptions, або все разом). Під це проектуємо схему.

Налаштовуємо конфігурацію продуктів у Unity IAP через ProductCatalog або програмно через ConfigurationBuilder. Для мультиплатформових ігор — єдиний каталог із платформо-специфічними ID (Apple/Google часто вимагають різні ідентифікатори). Використовуємо документацію Apple StoreKit для налаштування sandbox-тестерів і перевірки підписок.

Реалізуємо повний цикл: ініціалізація UnityPurchasing.Initialize() → обробка ProcessPurchase → підтвердження ConfirmPendingPurchase() → видача товару → запис у базу. Якщо є бекенд — додаємо серверну валідацію з retry-логікою при таймаутах.

Для iOS додатково: налаштування StoreKit середовища для тестування (Xcode Sandbox), обробка промо-оферів через IAppleExtensions.SetStorePromotionOrder(), коректна робота з Family Sharing якщо потрібно. Для Android: налаштування тестових акаунтів у Google Play Console, перевірка роботи в alpha/internal треці до публікації.

Що входить у роботу

• Документація: архітектурна схема покупок, опис продуктів, діаграма транзакцій.
• Вихідний код: повний скрипт IAP-менеджера з підтримкою всіх платформ.
• Серверна частина: API для валідації receipt (опціонально) з ідемпотентністю та ретраями.
• Доступи: налаштування App Store Connect та Google Play Console, створення тестових акаунтів.
• Навчання: пояснення, як додавати нові продукти та обробляти помилки.
• Підтримка: консультації протягом тижня після здачі.

Гарантуємо, що після нашої інтеграції ваша гра пройде рев'ю Apple та Google з першої спроби, а chargeback-запити будуть виключені.

Тестування — окремий етап

Сценарії, які перевіряємо обов'язково:

1. Успішна покупка — consumable, non-consumable, підписка.
2. Покупка при відключенні мережі в момент транзакції — перевірка Pending та відновлення.
3. Повторний запит покупки — виключення дублів.
4. Відновлення покупок на новому пристрої.
5. Покупка на пристрої без платіжного методу — коректна обробка помилки.
6. Апгрейд/даунгрейд підписки — правильне оновлення дати закінчення.

Sandbox-тестування на iOS має обмеження — деякі сценарії (наприклад, billing retry) відтворюються тільки в TestFlight. На Android — через internal testing track з ліцензійними тест-акаунтами.

Терміни

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

Монетизація ігор: чому доходи не зростають?

Гра вийшла, DAU зростає, доходи стоять на місці. Часто монетизацію вшивають постфактум — купівлі, події, рекламу додають без системи. Переписувати після релізу дорого й довго, а спроба виправити «на льоту» ламає прогрес і б'є ретеншн. Ми проектуємо ці шари з першого дня, щоб вони приносили гроші, а не перетворювалися на технічний борг.

Чому доходи стоять на місці? (H2)

Більшість проблем монетизації — технічні: втрачені транзакції, зламані підписки, невалідні події. Наприклад, клієнт із казуальною грою на Unity втрачав 30% IAP-доходу через відсутність серверної валідації — гравці отримували товари за перехоплені receipt. Ми замінили схему — дохід виріс на 40% за перший місяць.

IAP: архітектура внутрішньоігрових покупок

Unity IAP SDK виглядає тривіально: каталог продуктів, колбек. На практиці ламається більшість проєктів — дублювання транзакцій, втрата покупок, вразливість до злому.

Клієнтська vs. серверна валідація

Базова схема з клієнтським receipt працює, поки її не розкривають. Зломщик підміняє відповідь магазину — отримує предмет безкоштовно. Правильне рішення — відправляти receipt на бекенд для верифікації через Apple App Store API або Google Play Developer API. Тільки після цього видавати товар і зберігати transaction_id. Без серверної валідації м’яка валюта або battle pass стають мішенню для replay-атак.

Типи продуктів

Підписки — найскладніший тип. Apple і Google по-різному рахують renewal, trial та скасування. Потрібен бекенд, який обробляє Server-to-Server сповіщення (App Store Server Notifications, Google Pub/Sub). Без цього до половини підписок втрачаються.

Відновлення покупок

На iOS без IStoreController.RestoreTransactions() магазин не пропустять. На Android відновлення необов’язкове, але підвищує довіру. Unity IAP робить це одним методом — тестувати обов’язково на реальному пристрої з TestFlight.

Рекламна монетизація

У гіперкежуалі та казуалі реклама — основне джерело доходу. Ключові SDK:

• AdMob — базовий, стабільний, але eCPM нижче середнього.
• IronSource (Unity LevelPlay) — медіатор, проводить аукціон між мережами в реальному часі.
• AppLovin MAX — альтернатива, часто виграє по eCPM у США та Європі.

Практичне правило: використовуйте медіатор (IronSource або MAX) з AdMob, Meta Audience Network та парою регіональних мереж. Пряма інтеграція одного SDK дає доходу на 30-60% менше при тому ж трафіку — перевірено на 20+ проєктах. Медіатор підвищує eCPM в середньому в 1.4 раза порівняно з одиночним SDK.

Як реклама впливає на ретеншн? (H3)

Rewarded video — найщадніший формат: гравець сам вирішує дивитися ролик за винагороду. Interstitial між рівнями ріже ретеншн, якщо показувати частіше ніж раз на 3-4 переходи. Новим гравцям у перші 24 години рекламу не показуємо — це знижує Day 1 retention на 15-25%. Для одного з клієнтів ми налаштували таймінги — Day 7 виріс на 18%.

Аналітика: архітектура подій

Тут найглибше. Більшість команд підключають Firebase Analytics, розкидають logEvent() і вважають, що аналітика готова. Через місяць даних немає або вони марні — схема подій не продумана.

Як спроектувати схему подій? (H3)

1. Визначте ключові питання (наприклад, де гравці застрягають у навчанні, який LTV за джерелами трафіку).
2. Для кожного питання складіть набір подій з параметрами.
3. Узгодьте назви з командою (єдиний неймінг).
4. Встановіть ліміти: не більше 500 унікальних типів подій (Firebase), 25 параметрів на подію.
5. Протестуйте pipeline на тестовому акаунті до релізу.

Приклад поганої події:

logEvent("level_complete");

Приклад хорошої події:

logEvent("level_complete", {
  level_id: "world_2_level_5",
  attempts: 3,
  time_spent_sec: 142,
  boosters_used: ["shield", "bomb"],
  session_id: "abc123",
  user_segment: "payer"
});

Перша говорить тільки «рівень пройдено». Друга дозволяє будувати воронки, сегментувати гравців, корелювати поведінку з доходом.

Стандартні категорії подій

Прогрес: tutorial_step_complete (окремо на кожен крок онбордингу), level_start, level_complete, level_fail, chapter_unlock.

Монетизація: iap_initiated (відкрив магазин або тапнув офер), iap_complete (з revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.

Залученість: session_start/session_end (з тривалістю), feature_used, push_notification_open.

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

У нормальному проекті стоять усі три. Без AppsFlyer ви витрачаєте бюджет на UA наосліп — він відстежує SKAdNetwork, рахує ROI по кампаніях, інтегрується з Facebook Ads та Google UAC. Для одного клієнта AppsFlyer допоміг знизити вартість встановлення на 25% завдяки точній атрибуції.

Хмарні збереження

Гравець, який втратив прогрес при зміні пристрою, з імовірністю 70% не повернеться. Варіанти:

• Unity Cloud Save (UGS) — швидко, key-value, безкоштовно до ліміту.
• PlayFab Player Data — гнучкіше, сегментація, умовний доступ.
• Firebase Firestore — для складних даних, реалтайм-синхронізація.

Синхронізуйте тільки критичне: рівень, куплені предмети, налаштування. Важкі файли (replay, скріншоти) зберігайте окремо. Наше рішення знижує втрату прогресу до 2% користувачів.

Що входить у вартість? (H2)

Після укладення договору отримуєте:

• Аудит поточної схеми монетизації та аналітики (якщо гра жива) або проектування з нуля.
• Архітектура IAP із серверною валідацією та підтримкою підписок.
• Інтеграція медіатора реклами (IronSource/MAX) та налаштування аукціону.
• Схема аналітичних подій з підключенням Firebase + GameAnalytics + AppsFlyer.
• Хмарні збереження та відновлення покупок.
• Документація по подіях, інструкція для геймдизайнерів.
• 2 тижні безкоштовної підтримки після релізу.

Додатково — доступ до дашбордів, навчання команди роботі з аналітикою.

Чому варто працювати з нами?

7+ років налаштовуємо монетизацію в мобільних іграх. 30+ проєктів — від гіперкежуалу до MMORPG. Стандарт подій, який ми розробили, збільшив конверсію в платіж на 20% у одного клієнта за місяць. Інший отримав зростання LTV на 35% після таргетованих оферів — це принесло додаткові $12 000 щомісяця. Гарантуємо прозорість даних: ви бачите, які події йдуть і скільки приносять. Сертифіковані партнери Unity, 5+ років на ринку.

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

• IAP + серверна валідація: від 5 до 10 робочих днів.
• Рекламна монетизація з медіатором: від 3 до 7 днів.
• Повний цикл (аналітика + IAP + реклама): від 2 до 4 тижнів.

Вартість розраховується індивідуально — замовте безкоштовну оцінку проекту через форму зворотного зв’язку.

Типові помилки (без заголовка, як абзац)

Відсутність серверної валідації робить систему вразливою до злому. Події без параметрів — 50% часу аналітики витрачається на розшифровку. Запуск реклами в перші 24 години вбиває ретеншн: 80% гравців не повертаються. Пряма інтеграція одного рекламного SDK втрачає 30-60% доходу. Усі ці помилки ми виправляємо в межах одного проекту.

Зв’яжіться з нами — розберемо ваш проект і запропонуємо план. Напишіть нам, і ми підготуємо розрахунок за 1-2 дні. Отримайте консультацію вже сьогодні.