Интеграция внутриигровых покупок (In-app purchases)
Unity IAP на первый взгляд выглядит просто: подключил пакет, зарегистрировал продукты, вызвал BuyProductID(). На практике — первый же InitializationFailureReason.PurchasingUnavailable в продакшене на iOS 17 заставляет провести несколько часов в документации StoreKit 2 и понять, что у тебя неправильно настроен entitlement для In-App Purchase в App Store Connect.
IAP-интеграция — это не «добавить SDK». Это связка между клиентом, платёжной системой магазина и бэкендом, которая должна работать корректно в условиях нестабильного интернета, прерванных транзакций и попыток мошенничества.
Где чаще всего падает
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).
Restore Purchases на iOS. Apple требует кнопку восстановления покупок для non-consumable и subscriptions — без неё приложение не пройдёт ревью. IAppleExtensions.RestoreTransactions() должен быть доступен из UI, а обработчик OnTransactionsRestored — корректно обновлять состояние инвентаря без дублей.
Отдельная боль — подписки. SubscriptionManager в Unity IAP умеет парсить дату истечения и статус renewal, но только при наличии валидного receipt. На Android с Google Play Billing Library 5+ нужно явно запрашивать queryPurchasesAsync при каждом старте — кеш устаревает.
Что делаем в рамках интеграции
Начинаем с аудита текущего состояния: есть ли бэкенд, нужна ли серверная валидация, какая монетизационная модель (consumable, non-consumable, subscriptions, или всё вместе). Под это проектируем схему.
Настраиваем конфигурацию продуктов в Unity IAP через ProductCatalog или программно через ConfigurationBuilder. Для мультиплатформенных игр — единый каталог с платформо-специфичными ID (Apple/Google часто требуют разные идентификаторы).
Реализуем полный цикл: инициализация UnityPurchasing.Initialize() → обработка ProcessPurchase → подтверждение ConfirmPendingPurchase() → выдача товара → запись в базу. Если есть бэкенд — добавляем серверную валидацию с retry-логикой при таймаутах.
Для iOS дополнительно: настройка StoreKit окружения для тестирования (Xcode Sandbox), обработка промо-офферов через IAppleExtensions.SetStorePromotionOrder(), корректная работа с Family Sharing если нужно.
Для Android: настройка тестовых аккаунтов в Google Play Console, проверка работы в alpha/internal треке до публикации.
Тестирование — отдельный этап
Сценарии, которые проверяем обязательно: успешная покупка, покупка при отключении сети в момент транзакции, дублирующий запрос покупки, восстановление покупок, покупка на устройстве без платёжного метода, апгрейд/даунгрейд подписки.
Sandbox-тестирование на iOS имеет ограничения — некоторые сценарии (например, billing retry) воспроизводимы только в TestFlight. На Android — через internal testing track с лицензионными тест-аккаунтами.
Сроки
| Сложность | Срок |
|---|---|
| Consumable IAP, одна платформа, без бэкенда | 2–4 дня |
| Полная интеграция (две платформы + серверная валидация) | 1–2 недели |
| Subscriptions с управлением на бэкенде + аналитика | 2–4 недели |
Стоимость рассчитывается после анализа архитектуры проекта и требований к монетизационной модели.