I'm trying to implement the in app billing service in my app (for test-purposes currently). Have tried to check out resources and documentation but I haven't found any on what the status means and for what purpose.
This is what I'm talking about in the console:
If I set it as Active, does it mean that I can only make a real transaction?, where as I want to test only. Kindly help me understand this in detail.
If the status is inactive, it means that the item won't be available for purchase nor for testing. Whereas if the item is active, it means the product is available for purchase for testing purposes(not published on the play-store) and for commercial purposes(published).
Check out this link creating a managed product
Related
I'm new to flutter. I want to check if user already has active GP subscription when my app starts.
In native I could use 'queryPurchasesAsync' for that, and I could check sub status even in offline-mode (Google Play cache).
But in Flutter I have only purchaseStream with purchaseDetailsList. It works after making purchase, but after restarting the app (even if I use InAppPurchase.instance.restorePurchases()) purchaseDetailsList length is 0 even though the subscription is active.
The package documentation lists all the examples except this one, although this is needed for any application with subscriptions.
How can I fix it?
So we want to support in-app billing via Google's billing API and via AliPay for China. I've written a method that should return either a GooglePlay or an AliPay billing client (whichever is available). I need a way to determine whether Google's billing service is available to the user so I know which client to return.
So far I've come across a few different options and I'm unsure which one is the one I need:
Create a ServiceConnection and check the result of IInAppBillingService.Stub.asInterface(service)
.isBillingSupported(3, context.packageName, "inapp")
Here's the full code: https://gist.github.com/first087/9088162
This is a bit tedious since I need to wait for the service to connect, get the asynchronous result and then return the correct billing manager, but at first glance seems to be exactly what I need.
Use the GoogleApiAvailability class and check the result of isGooglePlayServicesAvailable(context)
This option is a lot cleaner than the 1st one, but I'm unsure whether it returns what I need and also requires me to add the com.google.android.gms:play-services-base library to my project.
Check if the GooglePlay app is installed on the device.
This is the most unreliable option (I think), because you can manually install the app, even though it's not been pre-installed by the manufacturer, and then you might not be able to make purchases since you're in China and they don't allow that.
Has anybody had similar experience? How do I correctly determine whether the user can make purchases via the PlayStore?
So after testing the methods in China, with a phone that did and didn't have a the PlayStore app installed, here's what we found:
With PlayStore app installed and without VPN
GoogleApiAvailability.isGooglePlayServicesAvailable() returns code 2 - ConnectionResult.SERVICE_VERSION_UPDATE_REQUIRED
IInAppBillingService.isBillingSupported() returns code 3 - BillingResponse.BILLING_UNAVAILABLE
Without PlayStore app installed and without VPN
GoogleApiAvailability.isGooglePlayServicesAvailable() returns code 9 - ConnectionResult.SERVICE_INVALID
IInAppBillingService.isBillingSupported() returns code 3 - BillingResponse.BILLING_UNAVAILABLE
With PlayStore app installed and with VPN
GoogleApiAvailability.isGooglePlayServicesAvailable() returns code 0 - ConnectionResult.SUCCESS
IInAppBillingService.isBillingSupported() returns code 3 - BillingResponse.BILLING_UNAVAILABLE
Conclusion: The safest way to determine whether billing is actually available is via the isBillingSupported() method. If you don't want to use it via the "hacky" way shown in option 1 of the question, you can just instantiate a new BillingClient and wait for the callback of its startConnection() method.
Here's a gist of the coroutine I wrote which gives you one of the two implementations of a BillingManager depending on whether in-app billing via the PlayStore is available.
I have a "Base", "Normal" and a "Deluxe" App. "Base" is free, "Normal" costs 1$ and "Deluxe" costs 2$.
The "Base" app holds the entire logic for all content and shows the trial content at the same time. The "Normal" and "Deluxe" are only unlocker apps without any logic.
The "Base" app simple checks if the "normal" or "deluxe" apps are installed as well and shows the corresponding content. ( This is no security question, I am doing this with certs compare ... )
I am looking for a way to allow the Users, who already payed the "Normal" App to only pay another 1$ to unlock the Deluxe content.
What I evaluated so far, which I don't like :
I don't like to use inapp payment for several reasons, which I do not want to discuss here please :-)
I could create a "upgrade2Deluxe" and in the "Base"-App I could check if "Normal" and "upgrade2Deluxe" is installed and show the Deluxe Content. But I also don't like that, because the User will see 3 Apps on his device.
Do anyone have a idea howto do this in another way ?
I'm faced with a similar choice, and I'm still exploring a number of ideas:
although I also don't want to have in-app purchases in my Base app (which currently needs no permissions at all), I'm thinking that having in-app purchases in the Normal app will be acceptable, so the user installs the Base app (which holds all the Base + Normal code), and the first upgrade is to install the Normal app, then future upgrades are achieved by running the very limited upgrade code from the Normal app.
I intend that the user does not see multiple apps on their device - the Normal app will not declare any launcher intent, so will be hidden from the user
I'm looking to have the Base app change it's declared launcher activity so that the icon changes from Base to Normal (or beyond)
By keeping in-app billing out of the Base app, I keep the ability of that app to work on Kindle Fire and other devices outside the Google Play ecosystem.
Refund users $1 if they buy both normal and deluxe.
You cannot manipulate prices on a per-user basis. There also isn't anything stopping users from buying both normal and deluxe versions from the play store.
If your problem with IAP is having a server side component, you could use something like http://doc.applicasa.com/docs/content/android/#monetization to help.
You can make two versions of the app - Free(Base) & Premium(Deluxe).
Although I understand you do not want to implement IAP, however you could provide them some of the additional features(after the trial) via the In-app purchases that would transform your app to the Normal version as it seems the only viable option.
Now for the Deluxe app you have to make another app with all the features you want to provide & provide the link in your app for the user to download. After the download of the Deluxe app the user can delete the Free app!
This is the norm that developers follow for trial & full version apps ( Example: The Dictionary.com app in iOS)
I have multiple items in my app. I have two devices. If I buy item on first of these devices and then try to buy on another one the same item, i can't.(Google play intent shows message - Item already owned! And then it crashes....:-( ) Items in google play are marked as "managed per user account". And I do not have any problem with buying items.
Another problem is, if I try RESTORE TRANSACTION ACTION - I got result_developer_error ( which is partly weird....):D
These issues tested on Android 2.2,4.1
My question is:
Is there any possibility to allow to buy this item multiple times without need that the item is marked as "unmanaged"? (I mean on different devices by the phrase multiple times)
If there is possibility? Can it be done without server side where the info will be stored?
I know that the simpliest solution is to change product_type - But then I will loose the chance for restore transaction action....
I followed google api on implementing the in-apps
http://developer.android.com/google/play/billing/billing_overview.html
note: implemented v2 in - apps
Managed items are tied to your account. So if you buy on a different device with the same Google account, you will get the 'already owned' error. If you use unmanaged items, you can buy the item as many times as you want. In this case you might need to track item state on your own server, if required. If you are using a test account to test this, restore transactions doesn't really work. Should work with a published app though.
In-app billing v3 handles this differently and should be slightly easier to manage. If this is for a new implementation, consider switching (or at least evaluating) v3. Not clear how stable (or not) it is though, since it is pretty new.
I have finally solved this issue by implementing new v3 in app billing. It's quite simple to implement version3 and it supports checking for transactions in very very better way. If I could i would send plus one to google for version3. If you are lookng for solution for this issue use this site "Google in app billing version 3"
Is it possible to get the price of In App Products programmatically?
I would like to show the price of the in app product on my buy button. Is there any service provided by android like "getInAppProductPrice(productId)".
The reason I need this is because, if I edit the price of a product at a later time, I would like to get it reflected in my application buy button automatically rather than hard code the price.
In the android market checkout screen, the price is shown. So some service should be available? Is it open to us ?
V3 of in app billing now has such helper functions, you want getSkuDetails()
http://developer.android.com/google/play/billing/billing_reference.html#getSkuDetails
Unfortunately it does not support getting a list of all available products which would be nice to have
Android Market API was working fine till Dec 15th 2011. It is not working as of now.That API used to give information on the market app. You can retrieve data, but I have never heard of anything which would help the developer to programmatically change the pricing details.