- Библиотека для совершения покупок внутри приложений (Android In-App Billing v.3)
- ▌ Подготовка
- ▌ Использование
- ▌ Исходный код, примеры
- ▌ Заключение
- # In-app Billing
- # Consumable In-app Purchases
- Steps in summary:
- # Step 1:
- # Step 2:
- # Step 3:
- # Step 4:
- # Step 5:
- # Step 6:
- # (Third party) In-App v3 Library
- Android in-app purchases, часть 1: конфигурация и добавление в проект
- Создание подписки/покупки
- Сравнение процесса покупки с App Store Connect
- Получение списка продуктов в приложении
- Про Adapty
- Покупки в Android приложении — Play Billing Library
Библиотека для совершения покупок внутри приложений (Android In-App Billing v.3)
Checkout («касса», «кассовый аппарат») — это библиотека для совершения покупок внутри приложений на базе Android In-App Billing v.3. Основная цель — уменьшить время разработчика, затрачиваемое на внедрение платежей в Андроид приложения. Проект был вдохновлён библиотекой Volley, и проектировался для того, чтобы быть максимально простым в использовании, быстрым и гибким.
▌ Подготовка
Существует несколько способов подключить библиотеку в проект:
- Загрузить исходный код из github репозитория и скопировать его в свой проект
- Для пользователей Maven использовать следующую зависимость:
- Для пользователей Gradle использовать следующую зависимость:
- Загрузить нужный архив из репозитория
Библиотека требует com.android.vending.BILLING разрешение (permission).
Если вы подключили библиотеку как зависимость (например, в Maven или Gradle), то дополнительно делать ничего не надо. В противном случае, нужно добавить следующую строчку в AndroidManifest.xml:
▌ Использование
Библиотека содержит 3 основных класса: Billing, Checkout и Inventory.
Класс Billing обрабатывает запросы на покупку (см. методы IInAppBillingService.aidl) и управляет подкючением к сервису Google Play. Этот класс лучше всего использовать как синглтон, для того чтобы все запросы выстраивались в одну очередь и использовали один кеш. Например, класс приложения может выглядеть следующим образом:
Класс Billing можно использовать для выполнения запросов напрямую, но чаще удобнее использовать посредника — класс Checkout . Последний добавляет к каждому запросу тег, по которому запрос может быть отменён, что может быть полезным, например, в Activity . Checkout позволяет загрузить текущее состояние покупок через метод Checkout#loadInventory() . Также Checkout , а точнее его наследник ActivityCheckout , предоставляет доступ к PurchaseFlow , который в свою очередь осуществляет действия, нужные для покупки. Код класса Activity , в котором отображается список покупок, и который позволяет совершать покупки, представлен ниже:
▌ Исходный код, примеры
Исходный код доступен в моём репозитории на github. Там же вы найдёте исходный код тестового приложения (само приложение может быть установлено из Google Play). Всё под лицензией Apache License, Version 2.0.
▌ Заключение
В библиотеке есть над чем работать (например, не хватает покрытия тестами, и было бы неплохо иметь процедуру миграции из одной популярной библиотеки). Но в целом, ей уже можно пользоваться в продакшене, что я и делаю в своём приложении Say it right!.
Вопросы и пожелания приветствуются в комментариях к статье, а также в багтрекере на гитхабе.
UPD Для библиотеки есть тестовое приложение в Google Play. Для того чтобы совершать тестовые платежи нужно вступить в эту Google+ группу.
Источник
# In-app Billing
# Consumable In-app Purchases
Consumable Managed Products are products that can be bought multiple times such as in-game currency, game lives, power-ups, etc.
In this example, we are going to implement 4 different consumable managed products «item1», «item2», «item3», «item4» .
Steps in summary:
- — Add the In-app Billing library to your project (AIDL File). — Add the required permission in `AndroidManifest.xml` file. — Deploy a signed apk to Google Developers Console. — Define your products. — Implement the code. — Test In-app Billing (optional).
# Step 1:
First of all, we will need to add the AIDL file to your project as clearly explained in Google Documentation here
IInAppBillingService.aidl is an Android Interface Definition Language (AIDL) file that defines the interface to the In-app Billing Version 3 service. You will use this interface to make billing requests by invoking IPC method calls.
# Step 2:
After adding the AIDL file, add BILLING permission in AndroidManifest.xml :
# Step 3:
Generate a signed apk, and upload it to Google Developers Console. This is required so that we can start defining our in-app products there.
# Step 4:
Define all your products with different productID, and set a price to each one of them. There are 2 types of products (Managed Products and Subscriptions). As we already said, we are going to implement 4 different consumable managed products «item1», «item2», «item3», «item4» .
# Step 5:
After doing all the steps above, you are now ready to start implementing the code itself in your own activity.
MainActivity:
# Step 6:
After implementing the code, you can test it by deploying your apk to beta/alpha channel, and let other users test the code for you. However, real in-app purchases can’t be made while in testing mode. You have to publish your app/game first to Play Store so that all the products are fully activated.
More info on testing In-app Billing can be found here
# (Third party) In-App v3 Library
Step 1: First of all follow these two steps to add in app functionality :
1. Add the library using :
2. Add permission in manifest file.
Step 2: Initialise your billing processor:
and implement Billing Handler : BillingProcessor.IBillingHandler which contains 4 methods : a. onBillingInitialized(); b. onProductPurchased(String productId, TransactionDetails details) : This is where you need to handle actions to be performed after successful purchase c. onBillingError(int errorCode, Throwable error) : Handle any error occurred during purchase process d. onPurchaseHistoryRestored() : For restoring in app purchases
Step 3: How to purchase a product.
To purchase a managed product :
And to Purchase a subscription :
Step 4 : Consuming a product.
To consume a product simply call consumePurchase method.
bp.consumePurchase(«YOUR PRODUCT ID FROM GOOGLE PLAY CONSOLE HERE»);
For other methods related to in app visit github
Источник
Android in-app purchases, часть 1: конфигурация и добавление в проект
Всем привет, меня зовут Влад и я разработчик Android SDK для обработки платежей в мобильных приложениях в Adapty.
Внутренние покупки и в частности подписки являются наиболее популярным способом монетизировать приложение. С одной стороны, подписка дает разработчику возможность постоянно развивать контент и продукт, с другой стороны, благодаря им пользователь получает более высокое качество приложения в целом. Внутренние покупки облагаются 30% комиссией, но если пользователь подписан больше года или приложение зарабатывает меньше $1М в год, то комиссия составляет 15%.
Это первая статья из серии, посвящённой работе с внутренними покупками на Android. В этой серии мы охватываем темы от создания in-app purchases до серверной верификации платежей:
Android in-app purchases часть 1: конфигурация и добавление в проект. — Вы тут
В этой статье мы разберём, как:
создавать продукты в Google Play Console;
конфигурировать подписки: указывать длительность, стоимость, пробные периоды;
получать список продуктов в приложении.
Создание подписки/покупки
Перед тем, как мы начнем, убедитесь, что
Вы подписали все соглашения и готовы работать.
Перейдем к делу, а именно создадим наш первый продукт.
Переходим в наш аккаунт разработчика и выбираем нужное приложение.
Дальше в левом меню ищем секцию Продукты, выбираем Подписки и жмем на Создать Подписку.
Дальше попадаем в конфигуратор подписки, разберем важные вещи.
Создаем ID, который потом используем в приложении. Хорошо, когда в ID мы кодируем период подписки и какую-то еще полезную информацию. Это позволяет создавать продукты в одном стиле, чтобы в будущем было проще анализировать статистику по покупкам.
Название подписки, как пользователь ее увидит в магазине.
Описание подписки, пользователь тоже это увидит.
Скроллим ниже и выбираем период подписки, в нашем случае это неделя, и конфигурируем стоимость.
Обычно вы задаете цену в базовой валюте аккаунта, а система автоматически переводит цены в разные валюты разных стран. Но вы также можете поправить цену в конкретной стране вручную.
Обратите внимание, что Google сразу указывает налог в каждой стране, это очень круто, а в App Store Connect такого нет.
Скроллим ниже и опционально выбираем:
Бесплатный пробный период.
Начальная цена. Промо-предложение на первые периоды оплаты.
«Льготный период». То есть, если у пользователя проблема с оплатой, сколько дней вы продолжаете давать ему премиум доступ.
Возможность подписаться заново из Play Market, а не из приложения, после отмены подписки.
Сравнение процесса покупки с App Store Connect
Несмотря на то, что подписки значительно лучше монетизируются на iOS, админка Play Console выглядит намного удобнее. Она работает быстрее, лучше и проще структурирована, качественно локализована.
Сам процесс создания продукта предельно упрощен. Здесь мы описали, как создавать продукты на iOS.
Получение списка продуктов в приложении
После создания продуктов перейдем к созданию архитектуры в приложении для приема и обработки покупок. В целом процесс следующий:
Подключаем платежную библиотеку.
Разрабатываем структуру класса для взаимодействия с продуктами из Google Play.
Реализуем все методы обработки покупки.
Подключаем серверную верификацию покупки.
В этой части разберем первые два пункта.
Подключим Billing Library к проекту:
На момент написания статьи актуальной версией является 4.0.0. Вы можете в любой момент заменить ее на другую версию.
Создадим класс-обертку, который будет инкапсулировать логику взаимодействия с Google Play, и проинициализируем в нем BillingClient из библиотеки Billing Library. Назовем такой класс BillingClientWrapper.
Наш класс будет реализовывать интерфейс PurchasesUpdatedListener. Мы сразу переопределим его метод onPurchasesUpdated(billingResult: BillingResult, purchaseList: MutableList
?) , который вызывается после совершения покупки, но саму реализацию опишем уже в следующей статье.
Google рекомендует, чтобы одновременно было не больше одного активного соединения BillingClient’а с Google Play, чтобы колбэк о совершенной покупке не вызывался несколько раз. Для этого целесообразно иметь единственный экземпляр BillingClient в классе-синглтоне. Класс в примере выше сам по себе синглтоном не является, но мы можем провайдить его с помощью dependency injection (например, используя Dagger или Koin) таким образом, чтобы в один момент времени существовало не больше одного экземпляра.
Для совершения любого запроса с помощью Billing Library нужно, чтобы у BillingClient’а в момент запроса было активное соединение с Google Play, но в какой-то момент оно может быть утеряно. Для удобства напишем обертку, чтобы любой запрос выполнялся только при активном соединении.
Чтобы получить продукты, нам нужно знать их идентификаторы, которые мы задавали в маркете. Но для запроса этого недостаточно, нужно указать еще и тип продуктов (подписки или разовые покупки), поэтому общий список продуктов мы можем получить только путем «склеивания» результатов двух запросов.
Так как запрос на продукты асинхронный, нам нужен колбэк, в котором мы получим либо список продуктов, либо ошибку. Billing Library при ошибке возвращает один из определенных в ней BillingResponseCode, а также debugMessage. Создадим интерфейс колбэка и модель для ошибки:
Напишем приватный метод для получения данных о продуктах конкретного типа, а также публичный метод, который «склеит» результаты от двух запросов и вернет итоговый список продуктов или ошибку.
Таким образом мы получили информацию о продуктах (SkuDetails), где есть локализованные названия, цены, тип продукта, а для подписок еще и период платежа, а также информация о начальной цене и пробном периоде (если доступно данному пользователю). Финальный класс выглядит так:
На этом все, в следующих статьях мы расскажем о реализации покупок, тестировании и обработке ошибок.
Про Adapty
Как видите, в процессе добавления покупок в приложения на Android много нюансов. Если использовать готовые библиотеки, всё будет проще. Советую познакомиться с Adapty — SDK для in-app покупок. Он не только упрощает работу по добавлению покупок:
Встроенная аналитика позволяет быстро понять основные метрики приложения.
Когортный анализ отвечает на вопрос, как быстро сходится экономика.
А/Б тесты увеличивают выручку приложения.
Интеграции с внешними системами позволяют отправлять транзакции в сервисы атрибуции и продуктовой аналитики.
Промо-кампании уменьшают отток аудитории.
Open source SDK позволяет интегрировать подписки в приложение за несколько часов.
Серверная валидация и API для работы с другими платформами.
Познакомьтесь подробнее с этими возможностями, чтобы быстрее внедрить подписки в своё приложение и улучшить конверсии.
Источник
Покупки в Android приложении — Play Billing Library
И как это до сих пор на Хабре нет статьи об этом? Не дело, надо исправлять.
Есть 2 способа добавить In-App покупки в Android-приложение — старый и новый. До 2017 года все пользовались библиотекой от anjlab, но с июня 2017 года ситуация изменилась, Google выпустила собственную библиотеку для внутренних покупок и подписок — Play Billing Library. Сейчас последний считается стандартом.
Play Billing Library это очень просто.
Добавьте разрешение в манифесте.
Создайте инстанс BillingClient и начните соединение.
В метод onPurchasesUpdated() мы попадаем когда покупка осуществлена, в методе onBillingSetupFinished() можно запросить информацию о товарах и покупках.
Запросить информацию о товарах. Поместите querySkuDetails() в onBillingSetupFinished().
В коде вы могли заметить понятие SKU, что это? SKU — от английского Stock Keeping Unit (идентификатор товарной позиции).
Теперь в mSkuDetailsMap у нас лежит вся информация о товарах (имя, описание, цена), зарегистрированных в Play Console данного приложения (об этом позже). Обратите внимание на эту строку skuList.add(mSkuId);, здесь мы добавили id товара из Play Console, перечислите здесь все товары, с которыми вы хотите взаимодействовать. У нас товар один —sku_id_1.
Все готово к тому, чтобы выполнить запрос на покупку. Передаем id товара. Запустите этот метод, например, по клику на кнопку.
Теперь, запустив этот метод, вы увидите вот такое диалоговое окно (прим. картинки из Интернета).
Теперь если пользователь купит товар — его ему надо предоставить. Добавьте метод payComplete() и осуществите в нем действия, предоставляющие доступ к купленному товару. Например, если пользователь покупал отключение рекламы, сделайте в этом методе так, чтобы реклама больше не показывалась.
Все хорошо, но если пользователь перезапустит приложение, наша программа ничего не знает о покупках. Надо запросить информацию о них. Сделайте это в onBillingSetupFinished().
В purchasesList попадает список всех покупок, сделанных пользователем.
Делаем проверку: если товар куплен — выполнить payComplete().
Готово. Осталось это приложение опубликовать в Play Console и добавить товары. Как добавить товар: Описание страницы приложения > Контент для продажи > Создать ограниченный контент.
Примечание 1: Вы не сможете добавить товар пока не загрузите билд приложения в Play Console.
Примечание 2: Чтобы увидеть диалоговое окно о покупке, вам надо загрузить билд в Play Console, добавить товар и подождать какое-то время (
30 минут — 1 час — 3 часа), пока товар обновится, только после этого появится диалоговое окно и можно будет осуществить покупку.
Примечание 3: Ошибка Please fix the input params. SKU can’t be null — товар в Play Console еще не успел обновиться, подождите.
Примечание 4: Вы можете столкнуться с ошибкой Error «Your transaction cannot be completed», в логах как response code 6 пока будете тестировать. По каким причинам это происходит мне точно неизвестно, но по моим наблюдениям это происходит после частых манипуляций с покупкой и возвратом товара. Чтобы это починить перейдите в меню банковских карт и передобавьте вашу карту. Как этого избежать? Добавьте ваш аккаунт в Play Console в качестве тестировщика и покупайте только с тестовой карточки.
(Кстати, на Хабре работает система донейтов по кнопке под статьёй — прим. модератора).
Источник
