ошибка биллинга в андроид приложении
Android In-app Billing: от мобильного приложения до серверной валидации и тестирования
Всем привет! Недавно передо мной встала задача интегрировать биллинг в наш сервис, и, хотя изначально задача казалась довольно простой, в результате это вылилось в исследование длиной в месяц времени, кучу нервов и открытий. Результатом стало понимание того, что, несмотря на огромное количество документации, не все можно найти простым запросом в Google (а в некоторых местах документация предлагает откровенный бред, о чем я еще расскажу далее).
В результате биллинг от Google Play был успешно интегрирован в наш сервис, валидация покупок и подписок на серверной стороне работает. Кому стало интересно — добро пожаловать под кат: здесь будет полное описание всего, начиная от регистрации покупок в консоли управления Google Play, и заканчивая работой с подписками на своем бекенде.
Для начала коротко о пациенте. Я буду разбирать по кусочкам Google Play In-App Billing V3 а также облачный Android Publisher API, который и поможет нам как с валидацией покупок, так и при работе с подписками. Также не обойдем стороной Консоль управления Google Play — она тоже нам понадобится.
Зачем вообще это нужно?
Если у вас клиент-серверное приложение — то без валидации на сервере вам не обеспечить защиту от пиратства. И хотя можно просто валидировать цифровую подпись покупки на сервере, у запроса на Android Publisher API метода есть некоторые дополнительные возможности. Во-первых, вы можете получить информацию о покупке или подписке в любое время без привязки к устройству пользователя, а, во-вторых, вы можете получить более детальную информацию о подписках и управлять ими (отменять, откладывать и т. п.). К примеру, если вы хотите отобразить дату следующего платежа как в Google Play Music:
То вы можете получить ее только запросом на Android Publisher API.
Полный flow при интеграции биллинга таков:
1. Регистрация приложения в консоли Google Play и создание списка покупок.
2. Интеграция Android in-app billing в мобильном приложении.
3. Валидация покупок и подписок на сервере.
Часть 1: Регистрация приложения в консоли Google Play и создание списка покупок
1. Есть ваше приложение не было ранее загружено — подпишите ваше приложение вашим release-сертификатом и загрузите его в закрытое альфа-или бета тестирование.
All Applications / Ваше Приложение / APK / Alpha(Beta) Testing
2. Создайте список тестирования и активируйте его для выбранного вами (Alpha или Beta) типа тестирования.
3. Добавьте в этот список email-ы Google-аккаунтов, которые будет тестировать биллинг. Например, ваш личный email, с помощью которого вы вошли в Google Play на своем устройстве.
Внизу будет ссылка Opt-in URL: по этой ссылке нужно перейти всем пользователям, которые будут тестировать биллинг (и самому тоже), и согласиться на тестирование. Без этого вы не сможете совершать покупки в альфа/бета версии.
4. Перейдите во вкладку Settings / Account Details, найдите раздел LICENSE TESTING и в поле Gmail accounts with testing access добавьте те же email-ы, что и в прошлом шаге. Теперь с этих аккаунтов вы можете тестировать покупки — за них не будет взыматься плата.
Добавить метод оплаты все же придется — сам диалог покупки потребует этого, однако когда вы непострудственно увидите кнопку купить в приложении — будет указано, что это тестовая покупка.
5. Добавьте тестовые покупки в ваше приложение. Для этого пройдите в All Applications / Ваше Приложение / In-app Products и нажмите Add new product. Можете добавить одну покупку (Managed product) и одну подписку (Subscription). В качестве product id можно использовать что-то в стиле com.example.myapp_testing_inapp1 и com.example.myapp_testing_subs1 для покупки и подписки соответственно Нужно как минимум добавить название и описание, установить цену для продукта, выбрать страны, где он доступен (можете выбрать все), для подписки также выбрать период, и активировать продукт. После этого он станет доступен через некоторое время.
ВАЖНО: вы должны опубликовать приложение (как минимум в alpha/beta), иначе покупки работать не будут.
Коротко о типах покупок
1. Managed product (inapp) — одноразовая покупка. После покупки пользователем становится владельцем покупки навсегда, но также такая покупка может быть «использована» (consume) — например, для начисления каких то бонусов. После использования покупка исчезает и ее можно совершить еще раз.
2. Subscription (subs) — подписка. После активации у пользователя снимается определенная сумма раз в определенный период. Пока пользователь платит — подписка активна.
Когда наши покупки будут активированы — мы сможем получить информацию о них непосредственно в мобильном приложении (название, описание, цена в локальной валюте) а также совершить покупку.
Часть 2: Интеграция Android in-app billing в мобильном приложении
Для начала выполним некоторые манипуляции, чтобы работать с биллинг-сервисом в нашем приложении.
Скопируем файлик IInAppBillingService.aidl в наш проект:
IInAppBillingService.aidl это файл Android Interface Definition Language (AIDL), который определяет интерфейс взаимодействия с сервисом In-app Billing Version 3. Вы будете использовать этот интерфейс для выполнения биллинг-запросов с помощью IPC-вызовов.
Чтобы получить файл AIDL:
Откройте Android SDK Manager.
В SDK Manager найдите и раскройте секцию Extras.
Выберите Google Play Billing Library.
Нажмите Install packages чтобы выполнить установку.
Перейдите в папку src/main вашего проекта и создайте папку с именем aidl.
Внутри этот папки создайте пакет com.android.vending.billing.
Скопируйте файл IInAppBillingService.aidl из папки %anroid-sdk%/extras/google/play_billing/ в только что созданный пакет src/main/aidl/com.android.vending.billing
Добавим разрешение в манифест:
И в месте, где мы собираемся совершать покупки, подключимся к сервису:
Теперь можно приступать к работе с покупками. Получим список наших покупок из сервиса с описанием и ценами:
С помощью этого метода мы можем загрузить данные о доступных покупках.
Теперь мы можем прямо из приложения получить список покупок и информацию про них. Цена будет указана в той валюте, в которой пользователь будет платить. Эти методы надо вызывать в фоновом потоке, так как сервис в процессе может загружать данные с серверов Google. Как использовать эти данные — на ваше усмотрение. Вы можете отобразить цены и названия продуктов из полученного списка, а можете названия и цены указать в ресурсах приложения.
Самое время теперь что-то купить!
Отдельно хочется сказать про dataSignature. Пример ее проверки есть тут, но если ваша покупка валидируется на сервере — то это лишний шаг.
Также может быть полезной возможность получить информацию о уже совершенных покупках:
Это тоже нужно выполнять из фонового потока. Здесь вернется список покупок, которые мы совершили ранее. Также можно получить и список активных подписок.
Следующий шаг — использование покупки. Имеется в виду, что вы начисляете пользователю что-то за покупку, а сама покупка пропадает, давая таким возможность совершить покупку еще раз.
После этого вы уже не сможете прочитать данные о покупке — она будет недоступна через getPurchases().
Здесь наши возможности по использованию биллинга непосредственно на устройстве заканчиваются.
Часть 3: Валидация покупок и подписок на сервере
Это самая интересная часть, над которой я бился дольше всего. Все примеры будут на java, для которой Google предоставляет готовую библиотеку для работы со своими сервисами.
Библиотеки и для других языков можно поискать здесь. Документация по Google Publisher API находится тут, в контексте текущей задачи нас интересуют Purchases.products и Purchases.subscriptions.
По сути, главная проблема, с которой я столкнулся, это описание способа авторизации. Даже по самому описанию он выглядит как пятая нога у коня, но проблема не в том, что он не работает, а в том, что он в корне не верный для нашей задачи. Просьба к знатокам не кидаться в меня камнями: OAuth предназначен для работы с ресурсами клиента, в нашем же случае backend-сервис обращается за данными биллинга нашего собственного приложения.
И вот тут нам на помощь приходит IAM (Identy Access Management). Нам нужно создать проект в Google Cloud Console и зайти во вкладку Credentials, выбрать Create credentials → Service account key.
Заполните данные так, как показано на картинке:
Service account: New service account
Service account name: имя на выбор
Role: не выбирайте, она сейчас не нужна
Key type: JSON
Нажимаете Create. Вылезет окошко с предупреждением Service account has no role. Соглашается, выбираем CREATE WITHOUT ROLE. Вам автоматически загрузится JSON-файл с данными для авторизации аккаунта. Сохраните этот файл — в будущем он понадобится для того, чтобы авторизоваться на Google-сервисах.
Теперь возвращаемся на вкладку Credentials нашего проекта и видим внизу список Service account keys. Справа кнопка Manage service accounts — нажимаем на нее и видим:
myaccount@project-name.iam.gserviceaccount.com — это и есть id нашего аккаунта. Копируем его и идем в Google Play Developer Console → Settings → User Accounts & Rights и выбираем Invite new user.
Вставляем id аккаунта в поле Email, добавляем наше прилождение и ставим галочку напротив View financial reports.
Нажимаем Send Invitation. Теперь мы можем использовать наш JSON-файл для авторизации и Google API и доступа к данным покупок и подписок нашего приложения.
Следующий шаг — нужно активировать Google Play Developer API для нашего проекта. Идем в Google Developer Console → Library и ищем Google Play Developer API. Открываем его и нажимаем Enable.
Последний шаг настройки — идем в Google Play Developer Console → Settings → API Access.
В списке находим наш проект (на картинке выше это Google Play Android Developer, но там должно быть имя вашего проекта) и нажимаем Link.
Теперь перейдем к разработке серверной части
Как вы будете хранить JSON-файл с приватными данными IAM-аккаунта оставим на ваше усмотрение. Импортируйте Google Play Developer API в ваш проект (mavencentral) и реализуем проверку.
Данные о покупке нужно отправить с нашего приложения на сервер. Сама реализация проверки на сервере выглядит вот так:
Таким образом мы получаем возможность получить данные о нашей покупке непосредственно от Google, потому пропадает необходимость в проверке подписи. Более того, для подписок вы можете получить намного больше информации, чем непосредственно через IInAppBilligService в мобильном приложении.
В качестве параметров запроса нам нужны:
Детали по ProductPurchase и SubscriptionPurchase описаны в документации, не будем на них останавливаться.
Вместо заключения
Сначала казавшаяся простой задача по интеграции биллинга в наш сервис превратилась в путешествие через документацию, гуглинг и бессилие (OAuth, ты прекрасен), так как про использование IAM для целей доступа в документации ни слова. Серьезно, они предлагают вбить руками какой-то руками состряпанный URL в вашем браузере, добавить origin для редиректа в консоли управления проектом, и все это для того, чтобы получить одноразовый токен, который надо руками передать на сервер, после чего использовать весь флоу OAuth для получения доступа к данным биллинга. Это не говоря о том, что если вы не успеете использовать refresh-token, то вам придется получать новый токен — руками. Согласитесь — это звучит как полный бред для backend-сервиса, который должен работать без вмешательства человека.
Я надеюсь, что этой статьей помогу кому-то сэкономить немного времени и нервов.
Android in-app purchases, часть 4: коды ошибок от Billing Library и как не облажаться с тестированием
Привет, я Влад, core разработчик Adapty SDK для Android. Продолжаю серию статей про то, как внедрять внутренние покупки в приложение Google Play. Остальные посты можно найти по ссылкам:
Android in-app purchases, часть 4: коды ошибок от Billing Library и как не облажаться с тестированием. — Вы тут.
Сегодня мы поговорим о кодах ошибок, которые мы можем получить от Billing Library в методе getResponseCode().
Пример того, как мы передавали ошибки в свои колбэки, можно посмотреть в этой статье. С одной ошибкой мы уже знакомы по предыдущим статьям — это USER_CANCELED, когда пользователь закрывает диалог покупки, ничего не купив. Давайте познакомимся с остальными.
Коды ошибок
Начнем с самых простых ошибок – с говорящим названием ERROR (responseCode 6) и чуть более говорящим названием DEVELOPER_ERROR (responseCode 5). Для первого случая гугл пишет в документации «Fatal error during the API action», для второго – «Invalid arguments provided to the API». Например, я смог получить DEVELOPER_ERROR, когда для запроса querySkuDetailsAsync() в билдер в setType() передал пустую строку.
Но не всё так просто. Я пошел дальше и в методе launchBillingFlow() использовал измененный SkuDetails (вытащил json из SkuDetails реального продукта, поменял в нем productId и передал в конструктор новому SkuDetails). По сути это invalid argument, и я ожидал получить DEVELOPER_ERROR, но… получил ERROR.
Отдельного упоминания заслуживает текст, который показывается в диалоге в этом кейсе — сравните английский и русский вариант:
Это, конечно, был искусственный пример. Гораздо ближе к реальности кейс, когда гугл отклонил оплату. Если при тестировании покупок с тестовой карты, о чем мы расскажем в конце статьи, в диалоге покупки выбрать «test card, always declined», вернется также ошибка ERROR, но уже с адекватным текстом.
В третьей статье, где описывалась смена подписки, мы для одного из proration mode увеличили цену годовой подписки почти в 3 раза, но не сказали, какая там должна была быть ошибка, если бы мы этого не сделали. Исправляемся.
Так как там, получается, указан неправильный proration mode, по логике мы должны получить всё ту же DEVELOPER_ERROR. Но нет, мы получаем SERVICE_UNAVAILABLE (responseCode 2). Ее же мы получаем и если указать любое левое число в качестве proration mode (это int, а не enum, нас никто не остановит), и если указать неправильный purchaseToken. Смотрим в документацию про SERVICE_UNAVAILABLE – «Network connection is down». Так, стоп…
При этом еще мы видим интересный диалог.
Что еще любопытно – в кейсе с ERROR при закрытии диалога НЕ через кнопку «ОК» (то есть, теми способами, которые интерпретируются как возврат назад) в onPurchasesUpdated() пришло, собственно, ERROR, а в случае с SERVICE_UNAVAILABLE в аналогичном кейсе приходит USER_CANCELED (но если нажать «ОК» в диалоге, то мы, как и ожидали, получим SERVICE_UNAVAILABLE).
Ну и в случае с отсутствием интернета SERVICE_UNAVAILABLE тоже приходит, тут не соврали.
Вот остальные коды ошибок с небольшими комментариями, так сказать, honorable mentions.
BILLING_UNAVAILABLE (responseCode 3). Гугл поясняет, что «Billing API version is not supported for the type requested». Я смог воспроизвести эту ошибку, разлогинившись из Google-аккаунта, а также на Хуавее без Google Play Services. Возможно, она также воспроизведется на старых телефонах, где не обновляли Google Play.
ITEM_NOT_OWNED (responseCode 8). Возникает при попытке законсьюмить покупку, которой у нас нет. Например, повторно после успешного консьюма.
ITEM_ALREADY_OWNED (responseCode 7). А тут наоборот – при попытке купить продукт, который у нас уже есть. В таком кейсе просто нужно обновить UI и сделать кнопку покупки некликабельной.
Самая популярная ошибка
Последняя и, наверное, самая популярная ошибка в начале пути внедрения in-app purchases — это ITEM_UNAVAILABLE (responseCode 4). Она говорит о том, что продукт недоступен для покупки, но не говорит, почему. А причины могут быть самые разные: от тестирования на неправильном аккаунте или неправильной сборке до покупки неактивированного продукта.
Вот чек-лист, что нужно сделать, чтобы избежать ее при тестировании:
Отправить в ваш test track сборку с Billing Library. Это обязательное условие — при этом вы можете тестировать и на дебажных сборках с таким же applicationId, но важно, чтобы хотя бы один раз сборка с Billing Library была загружена в Play Console.
Добавить в этот test track гугл-аккаунты тестировщиков, что особенно актуально для internal testing или закрытой альфы/беты. Там же будет ссылка в разделе How testers join your test, по которой тестировщики должны будут принять приглашение.
Покупать можно только активированный продукт. После создания продукта в Play Console есть кнопка activate, более детально процесс создания продукта мы описывали в первой статье.
Удостовериться, что тестирование на устройстве проходит с гугл-аккаунта, который является тестировщиком. Очевидный пункт, но бывает всякое, и это тоже нужно проверить, если вы получили такую ошибку.
applicationId сборки, с которой тестируется покупка, должно полностью совпадать с applicationId из Play Console. Это особенно важно для тех, у кого добавляется суффикс в дебажных сборках.
Добавить email-адреса тестировщиков в раздел Setup → License Testing в левом меню аккаунта (не приложения), чтобы они покупали продукты бесплатно с тестовой карты, а не с реальной. Еще один плюс, что подписки в данном случае будут иметь тестовую длительность. Не связано с этой ошибкой, но тоже полезное знание.
Заключение
Ошибки способны сильно усложнить работу, поэтому всегда важно понимать, как они могут возникнуть. Учитывая, сколько шагов нужно пройти, чтобы получить доступ к продуктам, проще всего словить ITEM_UNAVAILABLE. Поэтому я надеюсь, что мой чек-лист вам поможет.
Про Adapty
Для более простой работы с ошибками советую попробовать Adapty SDK для внедрения внутренних покупок в приложения. Кроме технической части, Adapty даёт много преимуществ:
Встроенная аналитика позволяет быстро понять основные метрики приложения.
Когортный анализ отвечает на вопрос, как быстро сходится экономика.
А/Б тесты увеличивают выручку приложения.
Интеграции с внешними системами позволяют отправлять транзакции в сервисы атрибуции и продуктовой аналитики.
Промо-кампании уменьшают отток аудитории.
Open source SDK позволяет интегрировать подписки в приложение за несколько часов.
Серверная валидация и API для работы с другими платформами.
Познакомьтесь подробнее с этими возможностями, чтобы быстрее внедрить подписки в своё приложение и улучшить конверсии.
Эта версия приложения не настроена для выставления счетов через Google Play
когда я пытаюсь запустить свое приложение с помощью биллинга в приложении, я получаю сообщение об ошибке: «эта версия приложения не настроена для выставления счетов через Google Play. Регистрация справочный центр для получения дополнительной информации».
любая помощь о том, как решить эту проблему?
17 ответов:
эта ошибка может быть вызвана несколькими причинами.
вот список требований для тестирования Google IAB.
требования к испытанию:
Ahh нашел решение после попытки в течение нескольких часов.
то же самое произойдет, если ваша опубликованная версия не совпадает с версией вы тестируете на вашем телефоне.
вам нужно подписать свой APK с вашим живым сертификатом. Затем установите его на тестовое устройство. Затем вы можете проверить InAppBilling. Если вы тестируете приложение путем прямого запуска через eclipse на устройство (в режиме отладки), то вы получите эту ошибку.
Если вы используете android.test.purchased Как SKU, он будет работать весь путь, но у вас не будет developerPayload в вашем окончательном ответе.
Если вы используете свой собственный проект в элементе приложения вы можете проверить весь путь, но вы будете взимается, и поэтому придется вернуть его себе впоследствии.
вы не можете покупать товары с той же учетной записью gmail, которая используется для консоли разработки google play.
Если вы здесь с 2018 года, вам нужно скачать APK непосредственно из Play Store и установить «производный» APK. Возможно, это из-за того, что в игровом магазине Google есть функция «подписание приложений Google Play».
позвольте мне просто добавить, что случилось со мной, может помочь кому-то одному.
Это было в основном из-за подписания.
поскольку я добавил детали подписи в структуру проекта, Я думал, что каждый раз, когда я запускаю, ожидаемый подписанный apk устанавливается. Но был выбран тип сборки «debug».
ниже исправить решил проблему для меня.
Это произойдет, если вы используете другую версию apk, чем в google play.
в моем случае я видел одно и то же сообщение из-за разных подписей установленного apk и загруженного на рынок apk.
В отличие от многих ответов и комментариев на SO и других сайтах, вам не нужно выполнять предварительные тесты с альфа/бета-версией вашего продукта, который был загружен из Google Play на ваше тестовое устройство (процесс публикации альфа/бета часто съедает полдня). Также вам не нужно загружать и повторно загружать подписанный релиз apk из вашей студии разработчика на тестовое устройство.
была та же проблема, и она не была решена, прежде чем я прочитал сообщение от DZDomi. Внезапно оказалось, что в консоли разработчика Google есть параметр, который вам нужно включить. В разделе «in app purchases» есть строка для вашего продукта, а в крайнем правом углу есть статус для него. Он должен быть активным!
и введите здесь свои учетные записи
моя проблема была в том, что я попытался проверить его с помощью отладки.keystore, я имею в виду запуск его через eclipse.Я экспортировал его с хранилищем Ключей, с которым я опубликовал в альфа-режиме(он должен быть опубликован, прежде чем вы сможете его протестировать).установил его в свой телефон, и чем я мог бы проверить его нормально.
Если вы хотите отладить IAB, что вам нужно сделать, это:
отправить в google play версию вашего приложения с разрешением IAB на манифест:
добавить продукт в приложение на google play:администрирование биллинга в приложение
установите пользовательское хранилище ключей отладки со знаком:настройка Eclipse для использования подписанного хранилища ключей
проблема также возникает, когда вы добавили покупку в приложении после загрузки apk, но вы не опубликовали приложение в play store (альфа, бета и производство).
что в основном означает, что вы должны добавить покупку в приложении после того, как вы опубликовали apk в Play store (альфа, бета и производство). В противном случае вы не сможете приобрести или запросить покупку в приложении.
еще одна причина, не упомянутая здесь, заключается в том, что вам нужно тестировать на реальном устройстве. Когда эмулятор становится действительно хорошим,это простая ошибка.
недавно google внедрил изменения в своих системах, и поскольку вы загрузили хотя бы один APK на свою консоль, вы можете проверить свои запросы в приложении с помощью своего приложения с любым кодом / номером версии.
настроить gradle чтобы подписать отладочную сборку для отладки.