Is there a way in Google In-app payment API, to set the item's price from the app?
I'd like to create a donate-my-app button in my app. There'll be some pre-defined donation amounts (eg 1$, 5$, 10$, and so on).
But I'd like to offer a donation method, where my users can choose how many money will they donate to me. Is there a way to impelent this in Google In-app payment service?
As far as I know, not possible.
From the Google Play Console, you can set pre-defined SKUs for each amount.
Then, list those amounts in your app. Whenever a user selects one amount, make them actually "purchase" that SKU item. That way you get the money (minus the fee Google applies).
Other than that, if you want custom amounts, Try PayPal. It has an Android SDK https://github.com/paypal/PayPal-Android-SDK. (Personally, never used it).
Related
I am having confusion choosing a suitable product type of a commodity in my utility android application.
My application is of a kind where the user is benefitted through the number of 'slots' that they own. Think of it like the length of a ListView. My free application will feature a maximum length of that ListView upto 5. But if a user needs more List Items, they can buy subsequent List Item slots. The user should be able to buy as many as they like at 0.50$ each.
The problem is that, my in-app product neither comes under the definition of a 'managed product' alone, nor does it come under the definition of a 'consumable product' alone. I need the 'slot' product able to be purchased as many times as the user likes. But at same time, i also want Google Play to keep track of the ownership of the amount of slots per user.
As the documentation (and several tutorials out there) suggest:
If i want Google Play to store the purchase information for each item on a per-user basis, i will have to declare my product as a managed (non-consumable) product.
If i want my product able to be purchased many times, i would have to implement consumption for items that can be purchased multiple times.
The predicament is that i want both the features.
One bad solution is that I feature several slot products as unique products (alpha slot, beta slot, ... and so on), and then treat them as the same thing. However, i'd like to know of a solution that's more correct and sensible.
Another solution could be to make use of a separate cloud service to keep track of the number of slots bought by users, but i don't want that. That would be overkill. Also, i'd like to make use of the 'local caching' feature of Google Play Store.
I asked Google Play Developer Support if there were any way that Google Play Store could keep count of consumable in-app products. Turns out, at the moment, it is not possible.
Here is the actual reply (Nov 3, 2016):
I wanted to know whether Play Store also keeps record of the count of a
CONSUMABLE in-app item that a user has bought even after the user
uninstalls and then reinstalls the app?
In short, after user reinstalls, is there any way of knowing as to how many
of a single in-app item has the user ever bought?
Hi,
Thanks for contacting Google Play Developer Support.
I checked into it and the Play Developer Console doesn’t currently
support tracking every individual users every IAP purchase for
developers to see. Luckily, we place a high value on developer
feedback, and I’ll be sure to pass along your specific feedback to our
product team. We’re continually adding new features and functionality,
so please stay tuned.
You can always check the Android Developers Blog for any new features
and updates: http://android-developers.blogspot.com/
In my app i have several managed products which have a certain price. In the release week I want to make some of them free of charge. As the minimum price on Google Play Developer console is 0.5€, I'm not sure how to make those products free of charge and at the same time save its SKUs to the Google Play servers (as it happens on default purchase flow). I want that, because a user may delete the app and reinstall it later.
Is that even possible?
See In-app Promotions — Where Developers can create promo codes which users can redeem for content or features.
Promo codes let you give content or features away to a limited number of users free of charge. After you create a promo code, you can distribute it subject to the terms of service. The user enters the promo code in your app or in the Google Play Store app and receives the item at no cost.
You cannot change the price of an in-app product once it is published, and you can't sell an item for free. You will have to implement this yourself, maybe by keeping a record of SKUs that a user has access to that is separate from what Google Play gives you. When a user clicks "buy" for a product, pays for it, and consumes it, then add that SKU to the list. If you want to offer a free product, simply add that SKU to the list as well without going through the IAB flow.
I'm starting to make some in-app purchases on my future app, and i wish to ask some questions regarding the new API (3) of the in app billing library (shown here):
google says (here) that there are no more unmanaged items. this means that in order to have multiple consumable items, the play store cannot hold a counter, so you need to either consume the purchase right when you put it in the app, or only when you need it.
My question about it is how would you get the consumable items stay on multiple devices? for example, if the user purchased 2 health potions, and because of the new limitations, they both are stored only on the app itself of one device, how could the end user go to another device , run the app and see that he has 2 health potions?
is it possible to make some purchases for free on some cases, programmatically ?
it could be useful for testing or on some cases when i want to reward the user for something he has done . i might even want to do it completely transparent and without any dialogs.
i know that there is a sandbox mode but that's only available by adding specific accounts as test accounts .
the lecture speaks of a "developer payload" (here) that you can put on the purchases for better security. they said that the data should be an id of the user, but they don't say what id i should use (only gave an example of google plus , which many people don't have).
my question is: what should be used for the "developer payload" ? if i use the sample, what do they use, and is it safe to use it or should i change it ?
i also don't understand how could it be useful, since the play store should always hold data as to which user has which items, so how could the play store be fooled on this? or maybe they talk about protection from changing the apk of the app?
is it possible to make a transaction of multiple purchases ? if so, can i hide those that don't cost money ? and if all are for free, maybe not show anything at all ?
Answer 1)
The way I have found for the question 1 is given below.
if your application used server database(stored data on server using internet connection) then you can simply stored data for particular user,Like if user has purchased 2 health potions and when user trying to use that 2 health potion from the another device then simply checked it is purchased by that user previously or not. if it is already purchased by that user then simply restrict that user to purchase potions again.
Answer 2)
Google is provided trial period for the subscription product. so that user can purchase that item as $0.00 amount as a trial period and when time expired(time can be 7day or more) item can be changed it's type as subscription item with credit card information as like simple purchase flow.
but, you used word "pro grammatically and without any dialog" then according to my knowledge Google will not provide it for the single user or for the particular user. you can simply give trial period value in the Google console for the all application user.
check this link for more detail: "Free trials" http://developer.android.com/google/play/billing/billing_subscriptions.html#administering
Answer 3)
I would like to suggest you for the developer payload, first of all it is not mandatory you can pass either blank string or with developer payload. According to my knowledge it should be working like "security code" same as you given in the Google site while searching content "Some Random String".
how to use developer payload and what should be use for developer payload
check this link
Developer payload is useful for the application?
I think it is working like security code like Random String, and while you retrieve data you can verify that item that was purchased is same or not so that if in case some kind of hacker can be redirect to the other product then you can check it at response time, is it the same product as you are going to purchased or not and user can be protect from unnecessarily withdrawn money from his account.
and also check given link I have explained more for the developer payload.
Is it possible to get product price in local currency from the app itself. For example if I am selling Product1 with price of 1$ through Google Play In App billing. A customer from UK clicks on a button to purchase the product and the price at Google Play is shown in GBP. Can I get localized price in the app from Google Play so I can display it to the customer in its own currency?
The in-app billing v3 claims to be able to accomplish this:
The API also introduces a long-anticipated feature: the ability to query in-app product information directly from Google Play. Developers can now programmatically obtain an item's title, description and price. No currency conversion or formatting is necessary: prices are reported in the user's currency and formatted according to their locale
Source: http://android-developers.blogspot.com/2012/12/in-app-billing-version-3.html
Since you are asking this i suggest to just leave as it is.
This is more about economy rather than programming, and the problem is that the ratio between 2 currencies keeps changing every time and there is no way to calculate this because of the market and the actual evaluation is only given by the stock markets for a particular point in time.
There are 2 ways of thinking about this:
The merchant makes an evaluation about what is the average ratio between 2 currencies, he quantifies this value in real money and adds it to the final price, so he can avoid money loss or at least a good part of it
The merchant puts in place a mechanism for prices that, given real-time infos from the stock markets ( probably you have to pay for this ), calculates prices of real goods in real time or every time that the user wants to checkout his order.
If this is new to you don't say nothing about this, there are a lots of money that are burning and magically appearing every day in every stock exchange market, if you give a bad advice to your client he can be really disappointed and lose a lot of money.
Also different currencies are usually handled directly by credit card services, there is no reason to handle this by yourself, you can only risk more than it's worth doing it.
If your users wants to know the price in their currency teach them to use Google or some reliable online currency converter.
I am in the process of creating an in-app-billing service. I want to set prices differently for different countries.
When the purchase page is displayed, how can I decide which currency i should use for an In-app-billing item? Do I use the local currency? Or the Android Market Account currency? I could not find any documentation about this. I want to know the rule of judgment to display the correct currency.
See this question and the corresponding answers:
Android Market In-App-Purchase: How to get the currency a user will pay in?
In summary, it's not possible (at the time of my writing this!) to talk to Android Market and get the currency of the user's Android Market account.
Maybe an idea to have a Spinner in your shop screen which allows the user to select the currency to display prices in. Bit of a hack but best alternative I could come up with.