Интеграция 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 растёт, но доходы не растут — или приходят, но непонятно откуда. Мы часто видим такую картину: монетизацию и аналитику вшивают постфактум, без системы. Переписывать покупки и события после релиза — дорого и долго. Наша задача — спроектировать эти слои так, чтобы они начали приносить деньги с первого дня, а не превратились в технический долг.

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+ проектах.

Как реклама влияет на ретеншн

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

Аналитика: архитектура событий

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

Как спроектировать схему событий?

До написания кода определите, на какие вопросы должна отвечать аналитика. Типичные вопросы:

• Где игроки застревают в обучении.
• На каком уровне происходит максимальный отвал.
• Какие источники трафика дают лучший LTV.
• Какие IAP-офферы конвертируются лучше.

Под каждый вопрос — конкретное событие с параметрами.

Пример плохого события:

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.

Облачные сохранения

Игрок, потерявший прогресс при смене устройства, с вероятностью 70% не вернётся. Варианты:

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

Синхронизируйте только критичное: уровень, купленные предметы, настройки. Тяжёлые файлы (replay, скриншоты) храните отдельно.

Что входит в нашу работу

После заключения договора мы:

• Проводим аудит текущей схемы монетизации и аналитики (если игра уже живая) или проектируем с нуля.
• Разрабатываем архитектуру IAP с серверной валидацией и поддержкой подписок.
• Интегрируем медиатор рекламы (IronSource/MAX) и настраиваем аукцион.
• Проектируем схему аналитических событий и подключаем Firebase + GameAnalytics + AppsFlyer.
• Реализуем облачные сохранения и восстановление покупок.
• Предоставляем документацию по событиям и инструкцию для геймдизайнеров.
• Даём 2 недели бесплатной поддержки после релиза.

Почему стоит работать с нами

Более 7 лет настраиваем монетизацию в мобильных играх. Опыт — 30+ проектов, от гиперкежуала до MMORPG. Разработали стандарт событий, который увеличил конверсию в платёж на 20% у одного из клиентов за месяц после внедрения. Гарантируем прозрачность данных — вы всегда видите, какие события идут и сколько приносят.

Сроки ориентировочно

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

Типичные ошибки, которые мы исправляем

• Отсутствие серверной валидации — уязвимость к взлому.
• События без параметров — данные бесполезны.
• Запуск рекламы в первые 24 часа — убивает ретеншн.
• Прямая интеграция одного рекламного SDK — теряете 30-60% дохода.

Закажите консультацию — разберём ваш проект и предложим план. Свяжитесь с нами через форму обратной связи.