Android in app purchase

Android in app purchase

I’ve implemented Google In-App Billing V3 in my app and i did my first test purchase. Now, as seen that i want it consumable, but if i click the "Purchase" button again i receive an error, i’m wondering how and where to insert "consumePurchase". I’ve been all day long on my computer searching on every thread, but i’m making confusion with old versions of the same. From what i saw, i need to call consumePurchase after the successfully purchased item AND when the activity is created, but i can’t figure out how to do it.

Is this the one and only line of code?

If so, what is "token"?

P.s. the consumable items are: 50, 150 and 300 coins that the user can buy to take a little advantage in the game.

Aaah, so confusing for me :/

2 Answers 2

The response intent to the purchase includes several fields, one of them being:

INAPP_PURCHASE_DATA A String in JSON format that contains details about the purchase order. See table 4 for a description of the JSON fields.

Inside that JSON, you have several fields, also explained in that page, the one you are looking for is:

purchaseToken A token that uniquely identifies a purchase for a given item and user pair.

All these is quite easy to follow from the official sample application, which I recommend you to download and try out, also to check the code.

Это нормально и безопасно установить значение в SharedPreference, чтобы отметить, что пользователь приобрел этот элемент? Что делать, если пользователь взломал это значение в SharedPreference. Или мне нужно каждый раз подключать IAP-сервис, чтобы проверить, прежде чем пользователь сможет его использовать?

(1) Какова наилучшая практика при использовании Google Android IAP V3?

(2) Кроме того, если на устройстве пользователя не установлен Google Play, я могу использовать PayPal для оплаты, но как отслеживать покупку и разблокировать функции для пользователей, если я попрошу пользователя использовать простой платеж в PayPal, чтобы получить лицензию ключ? Я не хочу использовать какой-либо другой платежный SDK, если на веб-странице Paypal купить лицензию. Как это реализовать?

(1) Какова наилучшая практика при использовании Google Android IAP V3?

-> официальный документ говорит, что только транзакция платежа будет обрабатываться самой игрой google, но в приложении вам необходимо настроить свою бизнес-логику, как вы обрабатываете интеграцию пользовательского интерфейса и другие вещи после покупки продукта. Вы также можете пойти с покупкой приложения v3.

(2) Кроме того, если на устройстве пользователя не установлен Google Play, я могу использовать PayPal для оплаты, но как отслеживать покупку и разблокировать функции для пользователей, если я попрошу пользователя использовать простой платеж в PayPal, чтобы получить лицензию ключ? Я не хочу использовать какой-либо другой платежный SDK, если на веб-странице Paypal купить лицензию. Как это реализовать?

-> Вы можете попросить пользователя обновить версию игры Google динамически. В документе разработчика Google говорится, что более 90% устройств используют 2,2 ОС с установленным магазином воспроизведения Google. Я не мог сказать ничего о транзакции PayPal, потому что я не использовал ее раньше, но да в покупке приложения с помощью v3 очень просто реализовать и понять процесс оплаты.

Как использовать в своем приложении

Три способа управления данными вашего приложения.

1) SharedPrefrence: вы можете использовать значение привилегии share и проверить, куплено ли оно или нет. Если в случае, если пользователь удалил приложение, а затем переустановил приложение, вы можете проверить, был ли пользователь приобретен или нет, при этом вы приобретаете товар уже купленный. И вам нужно управлять пользователем для доступа к вашим данным приложения.

2) локальная база данных: вы также можете использовать локальную базу данных sqlite для хранения деталей покупки и статуса покупки. И то же самое, что и выше, если пользователь очищает данные или удаляет приложение, а затем запрашивает элемент покупки снова и проверяет, был ли пользователь приобретенным или нет.

или

2) База данных сервера. Это лучший способ сравнить с приведенным выше, если вы используете веб-сервер для хранения пользовательских данных. В этом типе вам даже не нужно управлять во второй раз для случая, если пользователь удалит приложение или очистит данные приложения.

3) obfuscation: (Самый эффективный способ сравнения с общим преимуществом)

РЕДАКТИРОВАТЬ:

Это нормально и безопасно установить значение в SharedPreference, чтобы отметить, что пользователь приобрел этот элемент? Что делать, если пользователь взломал это значение в SharedPreference. Или мне нужно каждый раз подключать IAP-сервис, чтобы проверить, прежде чем пользователь сможет его использовать?

Читайте также:  Html ссылка на середину страницы

Пока я ищу в Интернете, я нашел ответ Nikolay Elenkov’s как Nikolay Elenkov’s ниже:

Если вы просто сохраняете флаг в общих предпочтениях, любой пользователь с корневым устройством может щелкнуть флагом по своему желанию и «подписаться» без оплаты. Таким образом, вы должны хотя бы сделать обфускацию. Вот примерный способ сделать это. Кроме того, существует API для проверки состояния подписки, поэтому вы должны периодически проверять, чтобы подписка была действительной.

Подробнее проверка ответа Николая Еленкова

Что лучше всего для выставления счетов? Или в покупке приложения или в Paypal?

Это зависит от типа продукта,

-> В биллинге приложений: лучше всего для Google в биллинге приложений,

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

-> Paypal: Лучше всего для выставления счетов в Paypal,

Для физического контента или продукта вы хотите поделиться. Вам не разрешается продавать физические товары или услуги, используя «In-App Purchasing», поскольку товары, приобретенные с помощью этого метода, должны напрямую относиться к приложению, использующему их.

Покупка физического продукта из приложения iPhone без покупки Apple в приложении

Надеюсь, это поможет вам.

Поскольку клиент Google Play теперь кэширует информацию о выставлении счетов In-app локально на устройстве, вы можете использовать API версии 3 для более частого запроса этой информации, например, посредством вызова getPurchases. В отличие от предыдущих версий API многие вызовы API 3 будут обслуживаться с помощью поиска в кеше, а не через сетевое подключение к Google Play, что значительно ускоряет время ответа API.

В основном это означает, что вы можете каждый раз искать покупку, и приложение Play Store будет реагировать почти сразу.

Как сказал Kuffs, лучше всего спросить о внедрении библиотеки In-App Billing на стороне приложения, которая, в свою очередь, запрашивает клиент Google Play устройства. Это гарантирует, что история покупок, полученная недавно с серверов Google Play, будет надежной и относительно свежей информацией.

Также имейте в виду, что если вы распространяете приложение в Google Play, вы ДОЛЖНЫ использовать механизм оплаты Google Play через In-App Billing. В настоящее время Google Play и Кошелек еще не поддерживают методы Paypal или проводного / банковского перевода, поэтому вам не следует интегрировать этот параметр, если вы его отпустите в Play.

Всем привет! Недавно передо мной встала задача интегрировать биллинг в наш сервис, и, хотя изначально задача казалась довольно простой, в результате это вылилось в исследование длиной в месяц времени, кучу нервов и открытий. Результатом стало понимание того, что, несмотря на огромное количество документации, не все можно найти простым запросом в 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) и создайте ваше первое приложение. Начнем с того момента, когда ваше приложение уже зарегистрировано.

Читайте также:  Adware removal tool на русском

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. Пример ее проверки есть тут, но если ваша покупка валидируется на сервере — то это лишний шаг.

Также может быть полезной возможность получить информацию о уже совершенных покупках:

Это тоже нужно выполнять из фонового потока. Здесь вернется список покупок, которые мы совершили ранее. Также можно получить и список активных подписок.

Следующий шаг — использование покупки. Имеется в виду, что вы начисляете пользователю что-то за покупку, а сама покупка пропадает, давая таким возможность совершить покупку еще раз.

Читайте также:  Iconbit hds6l прошивка 2018

После этого вы уже не сможете прочитать данные о покупке — она будет недоступна через 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-сервиса, который должен работать без вмешательства человека.

Я надеюсь, что этой статьей помогу кому-то сэкономить немного времени и нервов.

Ссылка на основную публикацию
Adblock detector