Рано или поздно наступает момент, когда разработчику нужно задуматься о том, как монетизировать своё приложение, чтобы оно приносило доход. Есть различные бизнес-модели, с помощью которых можно этого достичь, однако наиболее популярной является использование рекламы в приложении. Одним из плюсов использования рекламы является то, что она хорошо сочетается с другой бизнес-моделью — покупками внутри приложения. Например, пользователь может заплатить некоторую сумму денег для того, чтобы отключить показ рекламы в приложении.
В этой статье мы рассмотрим, как можно реализовать встроенные покупки на примере своего приложения Менеджер паролей от Wi-Fi сетей.
Возможность покупок в приложениях реализована благодаря In-app Billing. In-app Billing — это сервис Google Play, который позволяет продавать цифровой контент внутри приложений. Этот сервис можно использовать для продажи широкого спектра контента, включая загружаемый контент, такой как мультимедийные файлы и фотографии, виртуальный контент, такой как уровни игры или различные вспомогательные предметы, премиальные услуги и многое другое.
Встроенные покупки можно подключить для любого приложения, опубликованного в Google Play. Ничего особенного для этого не требуется, только аккаунт разработчика Google Play Console и аккаунт продавца Google Wallet. Android SDK также содержит пример приложения с реализованными встроенными покупками.
Ваше приложение обращается к сервису In-app Billing с помощью API, который предоставляется приложением Google Play, установленным на устройстве. Затем Google Play передает платежные запросы и ответы на запросы между вашим приложением и сервером Google Play. Таким образом, ваше приложение никогда напрямую не связывается с сервером Google Play. Вместо этого ваше приложение отправляет запросы в приложение Google Play через межпроцессную связь (IPC) и получает от него ответы, нет необходимости поддерживать какие-либо соединения между вашим приложением и сервером Google Play.
In-app Billing поддерживает широкую совместимость, он работает на устройствах под управлением Android 2.2 (API 8) или выше, на которых установлена последняя версия приложения Google Play.
API In-app Billing предоставляет следующие возможности:
- Ваше приложение отправляет запросы с помощью модернизированного API, который позволяет пользователям легко запрашивать информацию о продукте из Google Play и заказывать продукты в приложении. API быстро восстанавливает продукты на основе прав пользователя.
- API синхронно передает информацию о заказе на устройство при завершении покупки.
- Все покупки регулируемы, т.е. Google Play отслеживает права пользователя на продукты. Пользователь не может владеть несколькими экземплярами одного продукта в приложении; только один экземпляр может принадлежать пользователю в любой момент времени.
- Приобретённые продукты могут быть использованы. В таком случае они возвращаются в бесхозное состояние и могут быть куплены снова.
- API обеспечивает поддержку подписки.
Есть разные способы, как встроить в своё приложение In-app Billing: можно это делать как вручную, так и используя сторонние библиотеки. Одной из таких библиотек является Checkout, которая уже содержит в себе готовую к применению реализацию сервиса. Ею и воспользуемся.
Checkout — это реализация In-app Billing API. Большим плюсом здесь является, что с помощью этой библиотеки можно сделать интеграцию встроенных покупок в приложение намного проще, чем если бы это делалось вручную с нуля.
Checkout решает общие проблемы, с которыми могут столкнуться разработчики при работе с покупками, например:
- Как отменить все запросы, когда активность уничтожена?
- Как запросить информацию о покупках в фоновом потоке?
- Как проверить покупку?
- Как загрузить все покупки с использованием данных continuationToken или SKU (уникальный идентификатор продукта)?
- Как добавить покупки с минимумом шаблонного кода?
Checkout может быть использован с любым фреймворком или без него. Он имеет четкое разграничение функциональности, доступной в разных контекстах: покупки могут быть сделаны только в активности, тогда как SKU может быть загружен в сервис или класс Application.
Перед началом работы библиотеку нужно добавить в проект. Для этого в файле build.gradle модуля приложения добавить зависимость в блок dependencies.
Для работы с покупками требуется специальное разрешение com.android.vending.BILLING, которое будет добавлено в AndroidManifest.xml автоматически с помощью Gradle. Вы также можете добавить его вручную, добавив в файл манифеста следующую строчку перед элементом :
Создадим экземпляр класса Billing в Application, откуда затем будем брать его при необходимости. Если у вас нет класса Application в проекте, вы можете легко создать его. Для этого нужно добавить в файле Andro , например:
После этого нужно поставить курсор на имя класса, нажать Alt + Enter и выбрать опцию "Create class", после чего Android Studio создаст его.
В этом классе нам нужно добавить следующий код:
BASE64_PUBLIC_KEY это ключ, который используется для установления безопасного подключения между вашим приложением и сервером Google Play. Получить этот ключ вы можете в Google Play Console, перейдя в раздел "Инструменты разработки" — "Службы и API". Там в "Лицензирование и продажа контента" вы увидите сгенерированный для вашего приложения ключ, который нужно будет добавить в приложение, например, объявить как строковую константу в классе Application.
Класс Billing это основной класс для работы с библиотекой, он отвечает за:
- подключение и отключение услуг биллинга;
- выполнение платежных запросов;
- кеширование результатов запросов;
- создание объектов Checkout;
- логирование;
Для того, чтобы избежать множественных подключений к службе In-app Billing, следует использовать только один экземпляр класса Billing, именно по этой причине мы и создаём его в классе Application.
Теперь в классе активности при её создании инициализируем экземпляр класса ActivityCheckout, который наследует от базового класса Checkout.
Класс Checkout это средний уровень библиотеки, он использует класс Billing в определённом контексте (в Application, активности или сервисе), проверяет, поддерживаются ли покупки на устройстве и выполняет запросы. ActivityCheckout это подкласс, который способен покупать различные предметы, для создания его экземпляра нужно вызвать метод Checkout.forActivity() и передать в параметры активность и экземпляр Billing.
Метод start() запускает созданный экземпляр и отправляет запрос, который проверяет, поддерживается ли биллинг на этом устройстве.
Метод createPurchaseFlow() создаёт постоянный поток для покупок со слушателем, который будет получать обновления данных о покупках. Код слушателя выглядит следующим образом:
Класс PurchaseListener наследует от EmptyRequestLisneter
, который имеет методы onSuccess() и onError(). В данном случае, если пользователь купит отключение рекламы или сделает пожертвование, то слушатель получит данные о покупке и выполнит нужные операции.
Теперь нужно создать экземпляр класса Invertory.
Класс Invertory загружает данные о продуктах, SKU и покупках. Его жизненный цикл связан с жизненным циклом Checkout, в котором он был создан.
Метод makeInvertory() создаёт экземпляр Invertory и привязывает его к нужному объекту Checkout.
Метод load() отправляет запрос на получение данных о продуктах и асинхронно загружает результат в callback. В параметрах формируется запрос, какие именно продукты нужно получить (в данном случае, все имеющиеся, а именно донаты и отключение рекламы). Код коллбека, который принимает результат запроса, представлен ниже:
Метод onLoaded() вызывается, когда все данные загружены. В нём проверяются различные данные о продуктах. Например, можно проверить с помощью поля supported можно проверить, поддерживается ли продукт, а метод getSku() возвращает идентификатор продукта. Если нужно узнать стоимость продукта на основе локали устройства, то следует вызывать getSku(TYPE).price.
Метод isPurchased() проверяет, был ли продукт куплен пользователем. В случае с рекламой это будет означать, что её следует отключать.
Теперь нужно отправлять платёжные запросы сервису. Для этого в настройках приложения есть две кнопки "Удалить рекламу" и "Поддержать проект материально".
Обработка кнопки отключения рекламы выглядит следующим образом:
С помощью данного метода формируется запрос на покупку продукта, результат которого будет получен коллбеком.
Аналогичным образом формируется запрос на донат.
Таким образом, с помощью библиотеки мы реализовали встроенные покупки в приложении без использования шаблонного кода.
Содержание
Как добавить In-app Billing в приложение : 6 комментариев
А физ. лицо может зарегистрировать Google Wallet? Или нужно ИП открывать?
Может, в этом плене Google очень демократичная компания. Выплаты начнутся по достижении порога в 100$
А как тестировать покупки? Я прописал в play console тестового пользователя и через него покупаю например рекламу. Деньги не списываются но покупка числиться у него в google play.
Но в классе InventoryCallback mPurchases = 0.
Как правильно тестировать?
Здравствуйте! К сожалению, насчёт тестирования не получится что-либо подсказать, попробуйте написать автору библиотеки на гитхабе.
Всем привет! Недавно передо мной встала задача интегрировать биллинг в наш сервис, и, хотя изначально задача казалась довольно простой, в результате это вылилось в исследование длиной в месяц времени, кучу нервов и открытий. Результатом стало понимание того, что, несмотря на огромное количество документации, не все можно найти простым запросом в 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 и создание списка покупок
Зайдите в Консоль управления Google Play (если у вас нет аккаунта — зарегистрируйте его за $25) и создайте ваше первое приложение. Начнем с того момента, когда ваше приложение уже зарегистрировано.
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 в мобильном приложении.
В качестве параметров запроса нам нужны:
- packageName — имя пакета приложения (com.example.myapp)
- productId — идентификатор продукта (com.example.myapp_testing_inapp1)
- token — уникальный токен покупки, который вы получили в мобльном приложении:
Детали по ProductPurchase и SubscriptionPurchase описаны в документации, не будем на них останавливаться.
Вместо заключения
Сначала казавшаяся простой задача по интеграции биллинга в наш сервис превратилась в путешествие через документацию, гуглинг и бессилие (OAuth, ты прекрасен), так как про использование IAM для целей доступа в документации ни слова. Серьезно, они предлагают вбить руками какой-то руками состряпанный URL в вашем браузере, добавить origin для редиректа в консоли управления проектом, и все это для того, чтобы получить одноразовый токен, который надо руками передать на сервер, после чего использовать весь флоу OAuth для получения доступа к данным биллинга. Это не говоря о том, что если вы не успеете использовать refresh-token, то вам придется получать новый токен — руками. Согласитесь — это звучит как полный бред для backend-сервиса, который должен работать без вмешательства человека.
Я надеюсь, что этой статьей помогу кому-то сэкономить немного времени и нервов.
This is a simple, straight-forward implementation of the Android v3 In-app billing API.
It supports: In-App Product Purchases (both non-consumable and consumable) and Subscriptions.
You project should build against Android 2.2 SDK at least.
Add this Android In-App Billing v3 Library to your project:
- If you guys are using Eclipse, download latest jar version from the releases section of this repository and add it as a dependency
- If you guys are using Andro >
- Open the Andro >
- Create instance of BillingProcessor class and implement callback in your Activity source code. Constructor will take 3 parameters:
- Context
- Your License Key from Google Developer console. This will be used to verify purchase signatures. You can pass NULL if you would like to skip this check (You can find your key in Google Play Console -> Your App Name -> Services & APIs)
- IBillingHandler Interface implementation to handle purchase results and errors (see below)
- overr >
- Call purchase method for a BillingProcessor instance to initiate purchase or subscribe to initiate a subscription:
Without a developer payload:
With a developer payload:
IMPORTANT: when you provide a payload, internally the library prepends a string to your payload. For subscriptions, it prepends "subs:
:" , and for products, it prepends "inapp:
: :" . This is important to know if you do any validation on the payload returned from Google Play after a successful purchase.
With a bundle of extra parameters:
Use these methods if you want to pass extra parameters, as documented here, you can provide a Bundle object.
Please note that this feature is only available if the target device is support the version 7 of the In App billing API.
That’s it! A super small and fast in-app library ever!
And don’t forget to release your BillingProcessor instance!
Instantiating a BillingProcessor with late initialization
The basic new BillingProcessor(. ) actually binds to Play Services inside the constructor. This can, very rarely, lead to a race condition where Play Services are bound and onBillingInitialized() is called before the constructor finishes, and can lead to NPEs. To avoid this, we have the following:
Testing In-app Billing
Here is a complete guide. Make sure you read it before you start testing
Check Play Market services availability
Before any usage it’s good practice to check in-app billing services availability. In some older devices or chinese ones it may happen that Play Market is unavailable or is deprecated and doesn’t support in-app billing.
Simply call static method BillingProcessor.isIabServiceAvailable() :
Please notice that calling BillingProcessor.isIabServiceAvailable() (only checks Play Market app installed or not) is not enough because there might be a case when it returns true but still payment won’t succeed. Therefore, it’s better to call isOneTimePurchaseSupported() after initializing BillingProcessor :
or call isSubscriptionUpdateSupported() for checking update subscription use case:
Consume Purchased Products
You can always consume made purchase and allow to buy same product multiple times. To do this you need:
Restore Purchases & Subscriptions
Getting Listing Details of Your Products
To query listing price and a description of your product / subscription listed in Google Play use these methods:
As a result you will get a SkuDetails object with the following info included:
To get info for multiple products / subscriptions on one query, just pass a list of product ids:
where arrayListOfProductIds is a ArrayList containing either IDs for products or subscriptions.
As a result you will get a List which contains objects described above.
Getting Purchase Transaction Details
As a part or 1.0.9 changes, TransactionDetails object is passed to onProductPurchased method of a handler class. However, you can always retrieve it later calling these methods:
As a result you will get a TransactionDetails object with the following info included:
Getting Purchase History
You can request most recent purchases using getPurchaseHistory method. Pass required type as "inapp" for one-time purchases and "subs" for subscriptions or use Constants.PRODUCT_TYPE_MANAGED and Constants.PRODUCT_TYPE_SUBSCRIPTION respectively.
As a result you will get a List of BillingHistoryRecord objects with following fields:
Please keep in mind that this API requires billing API of version 6 or higher, so you should check if it is supported beforehand:
Handle Canceled Subscriptions
Call bp.getSubscriptionTransactionDetails(. ) and check the purchaseInfo.purchaseData.autoRenewing flag. It will be set to False once subscription gets cancelled. Also notice, that you will need to call periodically bp.loadOwnedPurchasesFromGoogle() method in order to update subscription information
Promo Codes Support
You can use promo codes along with this library. Promo codes can be entered in the purchase dialog or in the Google Play app. The URL https://play.google.com/redeem?code=YOUR_PROMO_CODE will launch the Google Play app with the promo code already entered. This could come in handy if you want to give users the option to enter a promo code within your app.
Protection Against Fake "Markets"
There are number of attacks which exploits some vulnerabilities of Google’s Play Market. Among them is so-called Freedom attack: Freedom is special Android application, which intercepts application calls to Play Market services and substitutes them with fake ones. So in the end attacked application thinks that it receives valid responses from Play Market.
In order to protect from this kind of attack you should specify your merchantId , which can be found in your Payments Merchant Account. Selecting Settings->Public Profile you will find your unique merchantId
WARNING: keep your merchantId in safe place!
Then using merchantId just call constructor:
Later one can easily check transaction validity using method:
P.S. This kind of protection works only for transactions dated between 5th December 2012 and 21st July 2015. Before December 2012 orderId wasn’t contain merchantId and in the end of July this year Google suddenly changed orderId format.
The necessary proguard rules are already added in the library. No further configurations are needed.
The contents in the consumer proguard file contains:
Copyright 2014 AnjLab
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
