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

Сроки

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