Samsung ln app purchase что это за программа

Посетив магазин приложений, кроме Категорий, Топ-списков и Рекомендаций, мы увидим главные две группы приложений и игр — платные и бесплатные. С платными приложения все довольно просто и однозначно — вы покупаете приложение с полным набором его функций и всем наполнением. Дальнейшая судьба вашей покупки — доход распределяется между магазином приложений и его разработчиками. Когда вы сталкиваетесь с бесплатными приложениями, то скорее всего будете иметь дело с приложениями, которые содержат рекламу или приложениями с in-app покупками.

Создатели бесплатных приложений или игр практически всегда приходят к необходимости их монетизации. Ведь приложение — это не просто решение каких-либо проблем, это бизнес-идея, которая должна приносить деньги. Есть несколько путей монетизации — например, реклама в приложении, покупки в приложении (in-app покупки) или же смешанный вариант.

Согласно статистике 2019-2020 годов:

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

Как Выключить Встроенные Покупки Apps Store

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

Давайте вместе разберемся: In-app покупки — что это и какие они бывают?

In-app покупки в приложениях

Обращали ли вы внимание, что используя приложение, вы попадаете на всплывающее сообщение про in-app покупку?

Чаще всего, для приложений, внутренние покупки выглядят, как покупка полного, golden, экстра доступа ко всем возможностям приложения.

Обратите внимание, каким образом формируется обращение к пользователю. Покупка максимально аргументирована, вы получаете полное пояснение выгод и бонусов при ее совершении. Частым способом привлечение пользователей к in-app покупкам является триал — бесплатный пробный период, в течении которого вы сможете оценить функционал и продолжить пользоваться всеми возможностями приложения уже на платной основе.

Дальше, если проанализировать — когда именно возникает уведомление про возможность in-app покупки. Умение органично вписать уведомление и подвести пользователя к моменту in-app покупки очень важно. Представьте себя на месте юзера — вы зашли в приложение (да, вы его сначала нашли, т.е. ожидаете определенный функционал, и установили), и вместо интерфейса с пулом возможностей вы получаете уведомление о премиум доступе. Скорее всего это отпугнет пользователя, ведь, по логике, он устанавливал «бесплатное» приложение (уведомление о покупках в приложении может быть проигнорировано) и вместо возможности использования — получает прейскурант на различные уровни доступа. Остерегайтесь таких шагов, ведь вернуть пользователя в приложение будет проблематично.

Еще одним подходом будет совмещение рекламы в приложении с in-app покупкой. Пользователь может купить доступ к приложению без рекламы и таким образом получить комфортное и беспрерывное пользование не отвлекаясь на рекламные баннеры и всплывающие ролики или сообщения. Убрать рекламу — это можно отнести к единоразовым in-app покупкам. Довольно справедливый подход и для пользователя — есть возможность бесплатно пользоваться приложением, и для разработчика — монетизация путем внутренней покупки и размещение рекламы.

Как играть в заблокированные игры на iPhone

Купил и забыл?

Раз мы уже упомянули про единоразовую покупку в приложении — без рекламы, то стоит упомянуть и другие типы in-app покупок.

• многоразовые покупки.

Исходя из названия, вполне очевидно, что совершать их можно несколько раз, по мере необходимости. О них мы напишем немного позже, когда будем говорить о in-app покупках в играх — ведь именно там есть множество примеров: энергия, ресурсы и прочая исчерпаемая внутриигровая валюта или предметы.

• одноразовые покупки.

Самый распространенный тип покупки доступа без рекламы, одноразовая оплата за получения доступа к определенным возможностям, уровням игры или приложения.

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

Одним из основных правил in-app покупки является Freemium — условно бесплатное приложение. Это именно то, о чем мы говорили выше — возможность попробовать бесплатно. Отличным примером является подписка на музыку — Spotify предлагает free период, по истечению которого подписка активирована и вы оплачивали свой доступ.

In-app покупки только для игр?

Как вы уже можете сделать вывод — нет. Покупки внутри приложения являются отличным способом монетизации. Особенно, если мы говорим про приложения привычного пользования — у среднестатистического пользователя всегда можно обнаружить подписку на Youtube, Spotify, фотостоки, библиотеки или другие повседневные приложения.

Основные советы по in-app покупкам:

• Предлагайте выбор — никто не любит, чтобы его загоняли в угол. Обеспечьте вашим пользователям возможность заработать виртуальные бонусы/баллы/валюту путем пользования приложением или игрой, и делать виртуальные покупки «по смешанному курсу”. Если что-то можно получить практически за “просто использование», а что-то только за реальные деньги — это вызывает доверие к вашему приложению или игре и в тоже время приводит к in-app покупкам и доходам.
• Дайте возможно попробовать все — free trial наш лучший друг в вопросе ознакомление пользователя со всеми плюшками и фичами приложения или игры. Платим за то, что нравится — довольный пользователь равен in-app покупке.
• Не заставляйте вашего пользователя искать что-то подобное вам, но за бесплатно. Ограничивая бесплатный функционал, делая его чуть менее удобным и привлекательным (но все же им можно пользоваться) — тем самым вы подталкиваете пользователя к upgrade и платному доступу.
• Пакетный предложения и акции — уведомление полученное в удачный момент, с волшебным словом скидка или 2 в 1 всегда будет способствовать in-app покупкам. Сложите несколько вариантов покупки вместе — пакетные предложения пользуются популярностью.
• Усложнение процесса и экономия времени — особенно это применимо к внутриигровым покупкам, когда игрок, желая ускорить или облегчить прохождение игры, приходит к in-app покупке.
• Ранжируйте ценовые планы — не давайте выбирать из самого дешевого или самого дорого доступа. Практически всегда будет выигрывать самый дорогой вариант, если есть средний (который немного дешевле).
• Удалить рекламу — один шаг и практически 100% in-app покупка.

In-app покупки в играх

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

Так как игровой процесс делает поведение пользователей более предсказуемым, внедрение внутренних покупкой дает отличные результаты. На старте, игра дает возможность игрокам ознакомится с процессом и ее постепенное усложнение приводит к необходимости совершения in-app покупки. Ускорение прохождения, дополнительные возможности и способности вашего персонажа — оружие, ресурсы, дополнительные артефакты. Все вышеперечисленное — это разовые внутренние покупки, которые расходуются по ходу игрового процесса и могут быть приобретены снова при необходимости.

Особенности in-app покупок в играх:

• как уже говори ранее, в бесплатных играх вы оставляете возможность их прохождения без in-app покупок, только на упорстве и мастерстве игроков. Тем самым, вы продлеваете время проведенное пользователями внутри игры.
• подход free или пробный период работает и для игр — обеспечьте игрока первоначальным запасом ресурса, чтобы он смог оценить его полезность и в дальнейшем приобретать его на платной основе.
• давайте возможность не просто совершить покупку, но и получить ее путем игрового процесса.
• одним из вариантов внутренних покупок для игр — улучшение, продолжение геймплея. Отличный пример, когда игрок вынужден ждать открытия новых уровней или локаций, а может купить быстрый доступ к ним.
• и наверное самое важное — предлагайте возможность in-app покупки вовремя. Игрок проиграл — дайте возможность повторить; не хватает ресурса — пополнить; экономит время — быстрое прохождение. Предложения покупки в правильный момент — путь к удачной монетизации.

P.S. Все советы по in-app покупкам можно применять как к приложениям, так и к играм.

С выходом iOS 11 речь пошла про оптимизацию in-app покупок. Так как внутренние покупки могут отображаться в списке вашего магазина приложений, в результатах поиска и также могут отображаться на вкладках игр или приложений в App Store. Как оптимизировать внутренние покупки на базе ASOMobile можно найти в нашем блоге.

Источник: vc.ru

Android in-app purchases: инициализация и обработка покупок

Это вторая статья из нашего цикла о реализации покупок на Android. В первой статье мы рассказывали о том, как создавать продукты в Google Play Console, сконфигурировать подписки и получить список продуктов в приложении.

В прошлой части мы создали класс-обертку для работы с Billing Library:

Класс-обертка для работы с Billing Library

Перейдем дальше к реализации покупки и дополним наш класс.

Создание экрана с подписками

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

На данном этапе для примера мы сделали упрощённый вариант пейволла:

Итак, на нашем пейволле располагаются следующие элементы:

Доработка кода для отображения информации о продуктах

В нашем примере четыре продукта:

• две автовозобновляемые подписки («premium_sub_month» и «premium_sub_year»);
• продукт, который нельзя купить повторно, — non-consumable (“unlock_feature”);
• продукт, который можно покупать много раз, — consumable (“coin_pack_large”).

Для упрощения примера будем использовать Activity, в которую заинжектим BillingClientWrapper из предыдущей статьи, и layout с жестко заданным количеством кнопок для покупки.

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

private val purchaseButtonsMap: Map by lazy(LazyThreadSafetyMode.NONE)

Объявим метод для отображения продуктов в UI, опираясь на логику из предыдущей статьи:

product.price — это уже отформатированная строка с указанием местной валюты для данного аккаунта, здесь никакое дополнительное форматирование не нужно; остальные поля в объекте класса SkuDetails также приходят уже с учетом локализации.

Запуск процесса покупки

Для проведения покупки необходимо вызвать метод launchBillingFlow() из главного потока приложения.

Добавим для этого метод purchase() в BillingClientWrapper :

fun purchase(activity: Activity, product: SkuDetails) < onConnected < activity.runOnUiThread < billingClient.launchBillingFlow( activity, BillingFlowParams.newBuilder().setSkuDetails(product).build() ) >> >

У метода launchBillingFlow() нет колбэка, ответ вернется в метод onPurchasesUpdated() . Помните, мы в прошлой статье его объявили, но оставили на потом? Вот сейчас он нам понадобится.

Метод onPurchasesUpdated() вызывается при каком-либо результате после взаимодействия пользователя с диалогом покупки. Это может быть успешная покупка, отмена покупки (пользователь закрыл диалог, в этом случае приходит код BillingResponseCode.USER_CANCELED) или же какая-то другая ошибка.

По аналогии с интерфейсом OnQueryProductsListener из предыдущей статьи, объявим в классе BillingClientWrapper интерфейс OnPurchaseListener , с помощью которого будем получать либо покупку (объект класса Purchase — о кейсе, когда он может быть null даже в случае успеха, расскажем в следующей статье), либо ошибку, которую мы также объявляли в предыдущей статье:

interface OnPurchaseListener < fun onPurchaseSuccess(purchase: Purchase?) fun onPurchaseFailure(error: Error) >var onPurchaseListener: OnPurchaseListener? = null

И реализуем его в PaywallActivity:

Добавим логику в onPurchaseUpdated():

override fun onPurchasesUpdated( billingResult: BillingResult, purchaseList: MutableList? ) < when (billingResult.responseCode) < BillingClient.BillingResponseCode.OK -> < if (purchaseList == null) < //to be discussed in the next article onPurchaseListener?.onPurchaseSuccess(null) return >purchaseList.forEach(::processPurchase) //to be declared below > else -> < //error occured or user canceled onPurchaseListener?.onPurchaseFailure( BillingClientWrapper.Error( billingResult.responseCode, billingResult.debugMessage ) ) >> >

Если purchaseList не пустой, для начала для каждой покупки делаем проверку, что ее purchasedState равен PurchaseState.PURCHASED, потому что покупки также могут быть отложенными, и в этом случае флоу на данном этапе прекращается.

Далее, согласно документации, нужно сделать серверную верификацию покупки, о ней мы расскажем в следующих статьях. После этого надо предоставить пользователю доступ к контенту и сообщить об этом в Google. Если не сообщить, то через три дня покупка автоматически отменится. Интересно, что это характерно только для Google Play, в то время как на iOS такого нет. Сообщить о предоставлении доступа к контенту можно двумя способами:

• с помощью acknowledgePurchase() со стороны клиента;
• либо Purchases.Products.Acknowledge/Purchases.Subscriptions.Acknowledge со стороны бэка.

В случае с consumable-продуктом вместо него нужно вызвать метод consumeAsync() , который под капотом делает acknowledge, а заодно дает возможность покупать этот продукт повторно. Это можно сделать только с помощью Billing Library: Google Play Developer API почему-то не предоставляет возможность делать это на бэкенде. Любопытно, что, в отличие от Google Play, в App Store и в AppGallery свойство consumable за продуктом жестко определено на уровне App Store Connect и AppGallery Connect соответственно. Справедливости ради, замечу, что консьюмить такие продукты из AppGallery нужно всё-таки явно.

Напишем методы для acknowledge и consume, а также две версии метода processPurchase() — в случае, когда у нас есть свой бэкенд и когда его нет.

private fun acknowledgePurchase( purchase: Purchase, callback: AcknowledgePurchaseResponseListener ) < onConnected < billingClient.acknowledgePurchase( AcknowledgePurchaseParams.newBuilder().setPurchaseToken(purchase.purchaseToken) .build(), callback::onAcknowledgePurchaseResponse ) >> private fun consumePurchase(purchase: Purchase, callback: ConsumeResponseListener) < onConnected < billingClient.consumeAsync( ConsumeParams.newBuilder().setPurchaseToken(purchase.purchaseToken).build() ) < billingResult, purchaseToken ->callback.onConsumeResponse(billingResult, purchaseToken) > > >

Без серверной верификации:

private fun processPurchase(purchase: Purchase) < if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) < onPurchaseListener?.onPurchaseSuccess(purchase) if (purchase.skus.firstOrNull() == «coin_pack_large») < //consuming our only consumable product consumePurchase(purchase) < billingResult, purchaseToken ->if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) < //implement retry logic or try to consume again in onResume() >> > else if (!purchase.isAcknowledged) < acknowledgePurchase(purchase) < billingResult ->if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) < //implement retry logic or try to acknowledge again in onResume() >> > > >

С серверной верификацией:

private fun processPurchase(purchase: Purchase) < if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) < api.verifyPurchase(purchase.purchaseToken) < error ->if (error != null) < onPurchaseListener?.onPurchaseSuccess(purchase) if (purchase.skus.firstOrNull() == «coin_pack_large») < //consuming our only consumable product billingClient.consumeAsync( ConsumeParams.newBuilder().setPurchaseToken(purchase.purchaseToken) .build() ) < billingResult, purchaseToken ->if (billingResult.responseCode != BillingClient.BillingResponseCode.OK) < //implement retry logic or try to consume again in onResume() >> > > else < //handle verification error >> > >

Подробнее о серверной верификации покупок мы расскажем в одной из следующих статей.

Во втором примере acknowledge, конечно, тоже можно было сделать на клиенте, но так как здесь у нас есть бэкенд, всё, что можно сделать на бэке, лучше отдать бэку. Что касается ошибок на acknowledge и consume, их нельзя игнорировать, потому что если ни одно из этих действий не произойдет в течение трёх дней после того, как покупка получила статус PurchaseState.PURCHASED, она отменится, а пользователю вернут средства. Поэтому, если мы не можем это сделать на бэкенде, и даже после нескольких повторных попыток всё еще получаем ошибку, самый надежный способ — получать текущие покупки пользователя в каком-нибудь методе жизненного цикла, например в onStart() или onResume(), и пытаться повторить в надежде, что пользователь в течение трёх дней зайдет в наше приложение при работающем интернете :).

Таким образом, текущая версия класса BillingClientWrapper будет выглядеть так:

Вы могли задаться вопросом, почему кнопки активны для всех продуктов, независимо от того, покупал их пользователь или нет. Или что будет, если купить обе подписки: заменит ли вторая первую или они обе будут сосуществовать. Всё это в следующих статьях 🙂

Источник: temofeev.ru

Android In-app purchasing: платное отключение рекламы в своём приложении

Много раз уже просили написать статью о том, как в приложении реализовать платное отключение рекламы. Вообще, реализовать рекламу легко, по In-app так же есть куча информации в официальной документации. Ну, если кому-то всё же статья пригодится, то хорошо.

In-App Purchase представляет собой сервис покупки виртуальных товаров внутри приложения (например игровой валюты, новых уровней и т.д.). Применяется он в основном в играх, в тех случаях, когда встает вопрос о необходимости заработка на своем творении.

В данной статье рассмотрю как можно использовать In-App Purchase для отключения рекламы в своём приложении.

Реклама в приложении

В принципе, можно взять любую площадку. Возьмём, к примеру AdMob. Я для удобства обычно подобные вещи в обёртки запихиваю, чтобы при смене площадки, если потребуется, почти ничего не пришлось менять. Обёртки для рекламной площадки должны реализовывать интерфейс:

public interface AdsControllerBase

Тогда обёртка для AdMob будет выглядеть примерно так:

Тогда инициализация рекламы будет такой:

AdsControllerBase ads = new AdMobController(this, layout);

При такой реализации в случае смены площадки, мы просто создадим инстанс другого класса. Для работы вам нужен лишь ID_приложения. который получите после создания в приложения в админке Admob.

In-app purchasing или внутренние платежи в приложениях

Для того, чтобы работать с системой покупок необходим файл IMarketBillingService.aidl. Лежит он в /user/android-sdk-linux/extras/google/play_billing директории с SDK. Положить файлик надо в com.android.vending.billing пакет вашего приложения.

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

Очень помогает официальная документация и пример из SDK.

Необходимо определить ключик в приложении — PublicKey, полученный при регистрации аккаунта на Android Market

Определяем IabHelper и инициализируем. Если удачно, то пытаемся восстановить покупки.

// id вашей покупки из админки в Google Play static final String SKU_ADS_DISABLE = «com.ads.disable»; IabHelper mHelper; private void billingInit() < mHelper = new IabHelper(this, BASE64_PUBLIC_KEY); // включаем дебагинг (в релизной версии ОБЯЗАТЕЛЬНО выставьте в false) mHelper.enableDebugLogging(true); // инициализируем; запрос асинхронен // будет вызван, когда инициализация завершится mHelper.startSetup(new IabHelper.OnIabSetupFinishedListener() < public void onIabSetupFinished(IabResult result) < if (!result.isSuccess()) < return; >// чекаем уже купленное mHelper. queryInventoryAsync(mGotInventoryListener); > >); >

mGotInventoryListener — слушатель для восстановления покупок.

// Слушатель для востановителя покупок. IabHelper.QueryInventoryFinishedListener mGotInventoryListener = new IabHelper.QueryInventoryFinishedListener() < private static final String TAG = «QueryInventoryFinishedListener»; public void onQueryInventoryFinished(IabResult result, Inventory inventory) < LOG.d(TAG, «Query inventory finished.»); if (result.isFailure()) < LOG.d(TAG, «Failed to query inventory: » + result); return; >LOG.d(TAG, «Query inventory was successful.»); /* * Проверяются покупки. * Обратите внимание, что надо проверить каждую покупку, чтобы убедиться, что всё норм! * см. verifyDeveloperPayload(). */ Purchase purchase = inventory.getPurchase(SKU_ADS_DISABLE); PreferencesHelper.savePurchase( context, PreferencesHelper.Purchase.DISABLE_ADS, purchase != null verifyDeveloperPayload(purchase)); ads.show(!PreferencesHelper.isAdsDisabled()); > >;

Теперь надо, собственно, саму покупку реализовать:

private void buy() < if(!PreferencesHelper.isAdsDisabled())< /* для безопасности сгенерьте payload для верификации. В данном примере просто пустая строка юзается. * Но в реальном приложение подходить к этому шагу с умом. */ String payload = «»; mHelper.launchPurchaseFlow(this, SKU_ADS_DISABLE, RC_REQUEST, mPurchaseFinishedListener, payload); >>

SKU_ADS_DISABLE — идентификатор товара, который вы создали в адмике Google Play. mPurchaseFinishedListener — слушатель:

// слушатель завершения покупки IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener = new IabHelper.OnIabPurchaseFinishedListener() < public void onIabPurchaseFinished(IabResult result, Purchase purchase) < if (result.isFailure()) < return; >if (!verifyDeveloperPayload(purchase)) < return; >if (purchase.getSku().equals(SKU_ADS_DISABLE)) < Toast.makeText(getApplicationContext(), «Purchase for disabling ads done.», Toast.LENGTH_SHORT); // сохраняем в настройках, что отключили рекламу PreferencesHelper.savePurchase( context, PreferencesHelper.Purchase.DISABLE_ADS, true); // отключаем рекламу ads.show(!PreferencesHelper.isAdsDisabled()); >> >;

Стоит отдельно поговорить о методе по верификации:

boolean verifyDeveloperPayload(Purchase p) < String payload = p.getDeveloperPayload(); /* * TODO: здесь необходимо свою верификацию реализовать * Хорошо бы ещё с использованием собственного стороннего сервера. */ return true; >

Сейчас нет никакой проверки покупок, но в реальном приложении вы должны сверять полученные данные с той сгенерированой строкой, что вы отправили в запросе на покупку. Проверять это надо на своём стороннем сервере. Для обычно приложения или офф-лайн игры это может и не критично, но для он-лайн игры это очень важно.

В принципе всё, теперь при запуске приложения просиходит проверка настроек (куда мы сохранили, что отключили рекламу):

PreferencesHelper.loadSettings(this);

После чего реклама уже не будет показываться.

Тестирование покупок

Сейчас довольно удобно тестировать своё приложение. Можно залить .apk как альфа/бета версию и опубликовать. При этом можно назначить группу в Google+, которая будет иметь возможность к тестированию. Если вы публикуете альфа или бета версию приложения, то в маркете она не появится, иметь доступ будет только эта группа.

Тестеры смогут осуществлять покупки. Деньги будут списываться без комиссии и будут возвращены после 15 минут после покупки. Так что, не беспокойтесь. Вот только у вас не получится протестировать приложение, если ваш аккаунт на устройстве и аккаунт издателя один и тот же =/

Полностью рабочий пример можете форкнуть с гитхаба.

Источник: suvitruf.ru