Інтеграція 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 з ліцензійними тест-акаунтами.

Терміни

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