SDK для внутриигровых покупок: сравнение Unity IAP, Google Play Billing и StoreKit

В проде начинаются подписки, восстановление покупок, задержанные платежи, смена требований Google, старые iPhone, спорные чеки и пользователь, которому предмет выдали дважды. Или не выдали вовсе. Красота.

SDK для внутриигровых покупок — это не просто прослойка между кнопкой в игре и витриной стора. Это кусок финансового контура продукта. Он должен корректно провести пользователя через платежный интерфейс, распознать состояние транзакции, не выдать премиум-валюту по поддельному чеку и пережить очередной обязательный апдейт библиотек магазина.

В этом сравнении Unity IAP, Google Play Billing и Apple StoreKit важен не абстрактный «лучший SDK». Его нет. Есть цена унификации, контроль над платформой и количество легаси, которое команда готова таскать за собой.

Unity IAP: удобный мост, а не отмена платформ

Unity IAP — кроссплатформенный SDK, который прячет за единым API нативные механизмы Apple StoreKit и Google Play Billing. Для команды на Unity это обычно самый рациональный старт: каталог продуктов, инициализация, покупка, обработка успешной транзакции и часть типовых сценариев живут в одном кодовом контуре.

На уровне игрового клиента это снимает вполне реальную боль. Вместо двух отдельных интеграций не нужно поддерживать два набора вызовов, различающиеся модели ошибок и разный жизненный цикл платежного диалога. Один идентификатор продукта можно связать с соответствующими сущностями в App Store Connect и Google Play Console, а затем использовать в общей игровой логике.

Но слово «абстракция» некоторые почему-то переводят как «можно ничего не понимать». Нет. Unity IAP сокращает платформенный оверхед, но не превращает Apple и Google в один магазин.

Unity IAP особенно уместен, когда игра действительно кроссплатформенная, а монетизация построена на обычном наборе: расходуемые товары, нерасходуемые разблокировки, подписки. В таком случае одна предметная модель покупки в коде — не маркетинг, а экономия на поддержке.

Однако этот мост надо обслуживать. Если Google меняет требования к Billing Library, Unity IAP должен подтянуть совместимую версию. Если Apple меняет поведение StoreKit или добавляет сценарии, критичные для вашего типа подписки, придется понимать, как это отражается в пакете Unity. Унификация не уничтожает зависимость. Она просто делает ее централизованной.

Универсальный SDK экономит код на старте. Продакшен проверяет, сэкономили ли вы при этом понимание — или просто отложили его до первого инцидента.

Где Unity IAP действительно выигрывает

У него есть три практических преимущества.

1. Общая бизнес-логика. Игра оперирует не двумя разными реализациями оплаты, а единым сценарием: запросили покупку, получили результат, отправили подтверждение на сервер, выдали entitlement. Это уменьшает вероятность, что Android-ветка уже умеет восстанавливать доступ, а iOS-ветка «пока потом».

2. Меньше дублирования в клиенте. Команде не приходится параллельно тащить отдельные адаптеры для StoreKit и BillingClient, синхронизировать интерфейсы и вручную выравнивать обработку типовых ошибок.

3. Проще поддерживать продукт с небольшой мобильной командой. Когда в штате нет отдельного сильного iOS-инженера и отдельного Android-инженера, кроссплатформенный слой помогает не строить платежную интеграцию из скотча, тревог и взаимных обещаний «документировать потом».

Но у Unity IAP есть и неприятная сторона: пакет становится частью критической зависимости. Его нельзя оставить в замороженном состоянии на два года только потому, что платежи однажды заработали. Магазины не впечатляются стабильностью вашего репозитория.

StoreKit 2 и Google Play Billing: версия библиотеки теперь часть релиза

Apple представила StoreKit 2 в 2021 году. Это современный слой для работы с покупками в экосистеме Apple, с более удобной моделью асинхронных операций и актуальными механизмами обработки транзакций. В современных версиях Unity IAP StoreKit 2 используется по умолчанию на устройствах с iOS 15 и выше. Для более старых версий iOS предусмотрен автоматический откат к StoreKit 1.

На бумаге это выглядит как прозрачная деталь реализации. На практике это означает, что одно и то же игровое событие может идти разными платформенными путями в зависимости от версии ОС. И да, такой хвост легаси никуда не денется, пока продукт поддерживает устройства ниже iOS 15.0.

На стороне Android темп изменений обычно жестче, потому что Google привязывает требования к публикации и обновлениям приложений. С августа 2025 года Google Play требует использовать Google Play Billing Library версии 7.0.0 или новее. Для Unity-проектов это означало необходимость обновить Unity IAP до совместимой ветки 5.x. В актуальных обновлениях пакета заявлена поддержка Google Play Billing Library версий 8.0.0 и 9.0.0.

Это не мелкий технический апдейт в духе «поправили пару warning’ов». Неподходящая версия библиотеки способна заблокировать нормальное обновление приложения в сторе. Самый дорогой баг в монетизации — не тот, который красиво падает в логах. Самый дорогой — тот, из-за которого вы не можете выкатить фикс.

Что включать в платежный регресс перед деплоем

Покупки нельзя проверять только счастливым путем: нажали кнопку, стор вернул success, персонаж получил сундук. Это тест уровня презентации, а не платежного контура. Минимальный набор сценариев для каждого релиза выглядит так:

• новая покупка расходуемого товара с однократной выдачей награды;
• повторная покупка того же расходуемого товара;
• нерасходуемая покупка и повторный запуск приложения;
• восстановление уже купленного контента на новом устройстве или после переустановки;
• активная подписка, отмененная подписка и ситуация с истекшим доступом;
• отмена пользователем платежного окна;
• отложенная или незавершенная транзакция, если такой сценарий возвращает стор;
• отказ или таймаут в сетевом слое между клиентом и вашим сервером;
• обновление приложения поверх версии с предыдущей реализацией IAP.

Последний пункт регулярно недооценивают. А зря. Внутриигровые покупки живут дольше конкретной версии клиента. Пользователь купил набор месяц назад, а вы сегодня поменяли Unity IAP, схему продукта или серверную модель прав доступа. Если миграция сделана на авось, прод очень быстро объяснит разницу между «товаром» и «правом пользователя на товар».

Комиссия стора: 30% — не ошибка в формуле

Разговор о выборе SDK для покупок в приложении часто незаметно превращается в разговор о цене интеграции. Но крупнейшая цифра в этой истории не в смете разработчиков. Ее удерживает площадка.

Стандартная комиссия Apple и Google составляет 30% от транзакции. При отдельных условиях она может снижаться до 15%:

• у Apple — для автопродлеваемых подписок после первого года;
• у Google — для первого миллиона долларов ежегодного дохода.

Эти проценты не зависят от того, используете вы Unity IAP или пишете интеграцию напрямую через StoreKit и Google Play Billing. SDK влияет на стоимость разработки, скорость реакции на изменения и число эксплуатационных рисков. Комиссию магазина он не «оптимизирует». Любой продавец, обещающий обратное, продает не инструменты для монетизации мобильных игр, а дымовую машину.

Для экономики игры это означает простую вещь: валовая цена набора кристаллов и деньги, доступные после комиссии стора, — разные сущности. В продуктовой модели полезно разделять как минимум:

• цену, которую видит игрок;
• сумму после комиссии площадки;
• налоги и иные удержания, если они применимы к конкретному рынку;
• стоимость привлечения платящего пользователя;
• стоимость поддержки платежей: сервер, мониторинг, разбор спорных транзакций, обновление SDK.

Последний пункт выглядит мелочью, пока не возникает необходимость экстренно обновлять платежную библиотеку перед дедлайном. Потом выясняется, что «бесплатный» пакет требует нескольких недель QA, релизного окна и людей, способных отличить проблему стора от собственной гонки состояний.

Комиссия в 15% или 30% видна в отчете. Цена плохой интеграции обычно прячется в возвратах, потерянных подписках и ночных созвонах.

Чек на клиенте — это сигнал, а не доказательство

Самый живучий антипаттерн в IAP-интеграциях выглядит так: клиент получил успешный callback, локально распарсил чек, сразу начислил валюту. Иногда туда еще добавляют обфускацию. Получается аккуратный замок, прикрученный к картонной двери.

Клиентское приложение находится у пользователя. Его можно модифицировать, перехватить сетевой трафик, подменить локальные ответы, повторить запрос. Каким бы удобным ни был SDK, отсутствие серверной валидации чеков оставляет систему уязвимой для мошеннических запросов на выдачу внутриигровых предметов.

Задача клиента — провести пользователя через нативную покупку и передать на сервер данные транзакции. Задача сервера — проверить, что транзакция существует, соответствует нужному продукту и еще не была использована для выдачи награды. После этого сервер фиксирует entitlement: право на предмет, премиум-функцию или подписочный доступ.

В нормальной архитектуре сервер — источник истины. Не потому что так написано в красивой схеме для инвестора, а потому что иначе вы не сможете надежно ответить на неприятный вопрос: «Почему этому аккаунту выдали 10 000 гемов по одному и тому же платежу?»

Минимальная дисциплина серверной проверки

Надежность строится не на одном API-вызове, а на нескольких скучных, но обязательных свойствах системы.

1. Идемпотентность выдачи. Каждая транзакция должна иметь уникальный ключ обработки. Повторная доставка одного и того же события не должна повторно начислять предметы. Сеть любит повторы. Очереди любят повторы. Пользователи тоже любят нажимать кнопку несколько раз.

2. Связка транзакции с продуктом и аккаунтом. Сервер проверяет не только факт оплаты, но и то, что она относится к ожидаемому SKU и корректно сопоставлена с игровым пользователем. Иначе появляется пространство для странных, очень творческих инцидентов.

3. Отдельное хранение прав доступа. Для нерасходуемых покупок и подписок полезно хранить не «когда-то был success», а текущую модель entitlement. Тогда восстановление доступа после переустановки становится штатной операцией, а не шаманством с локальным кешем.

4. Аудит и наблюдаемость. Нужны записи о входящем чеке, результате проверки, выданной награде и причинах отказа. Без этого финансовая поддержка превращается в театр теней: клиент говорит «купил», сервер говорит «не видел», аналитика показывает какой-то агрегат за сутки.

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

Unity IAP может облегчить доставку данных транзакции до вашей логики. Но валидировать чек за вас в продовой архитектуре он не должен и не может. Это уже зона вашей серверной части, вашей модели данных и вашей способности не делать необратимые действия по одному клиентскому сигналу.

Когда нативные SDK лучше универсального слоя

В споре Unity IAP vs Google Play Billing нередко пытаются выбрать победителя вообще. Это бесполезное упражнение. Google Play Billing не конкурирует с Unity IAP в полном смысле: он является нативным фундаментом Android-покупок, который Unity IAP оборачивает для Unity-проектов. То же справедливо для сравнения Apple StoreKit и Google Play Billing: это не два взаимозаменяемых продукта, а два платформенных мира с разными правилами и API.

Прямая интеграция StoreKit и Google Play Billing оправдана, когда общий слой начинает мешать сильнее, чем помогает.

Это происходит в нескольких случаях:

• продукт не построен на Unity или Unity в нем — лишь один из клиентов;
• критичны специфические возможности конкретного стора, которые нельзя удобно выразить через доступный слой абстракции;
• команда уже имеет зрелые нативные iOS- и Android-направления и общая обертка лишь добавит еще один уровень отладки;
• платежная логика настолько сложна, что ее все равно приходится строить вокруг собственного серверного домена, а клиентские адаптеры остаются тонкими;
• нужно очень быстро реагировать на новые требования конкретной платформы, не ожидая обновления промежуточного SDK.

Последний случай особенно неприятен. Промежуточный слой хорош, пока его релизный цикл не расходится с календарем платформы. Если Google выдвигает обязательное требование, а совместимое обновление вашего пакета еще не прошло внутреннюю проверку, команда оказывается между дедлайном стора и зависимостью в package manager. В такие дни абстракция ощущается не как инженерное решение, а как чужой легаси-код, который поселился в вашем релизном процессе.

При этом уходить в нативный код только ради ощущения контроля тоже не стоит. Два самостоятельных платежных контура требуют двух наборов тестов, двух дисциплин обновления и людей, которые реально умеют их сопровождать. Не «разберемся по документации», а умеют. После пятого инцидента разница становится особенно отчетливой.

Выбор без религиозной войны

Для стандартной мобильной игры на Unity Unity IAP обычно остается разумным выбором: он уменьшает дублирование и дает общий интерфейс к StoreKit и Google Play Billing. Но его нужно воспринимать как зависимость финансового контура — обновляемую, тестируемую и наблюдаемую. Не как коробку, которую однажды поставили в проект и забыли.

Нативные StoreKit и Google Play Billing стоит брать напрямую там, где платформенная специфика — не редкое исключение, а основа продукта. Это дороже в реализации и поддержке, зато дает прямой контроль над поведением каждой платформы и ее новыми возможностями.

Жесткий, но справедливый вердикт такой: выбор SDK для внутриигровых покупок определяется не красотой API и не количеством строк в quick start. Он определяется тем, кто будет обновлять интеграцию под новые требования сторов, кто отвечает за серверную валидацию и что случится с правами игрока после неудачного деплоя. Если на эти вопросы нет конкретных ответов, SDK уже выбран неправильно — даже если кнопка покупки пока работает.