Shared publicly  - 
In-app Billing is expanding again today, version 3 introduces the following new features:

* An improved design that makes applications simpler to write, debug and maintain.
* More robust architecture resulting in fewer lost transactions.
* Local caching for faster API calls.
* The ability to consume managed purchases and query for product information.

In-app Billing version 3 is available to any application that uses in-app items, and is supported by Android 2.2+ devices running the latest version of the Google Play store.

Joel Reeves's profile photoanton nasser's profile photoAlexander Biemann's profile photoJabes Pauya's profile photo
It would be amazing if you guys had an HTTP API for querying in-app purchases :)
Thanks for helping to make Android applications worse and worse.  I would never allow in-app billing in one of my applications, and those developers who do are a joke.  In my experience, all such apps that beg for money are worthless anyway.
Is there a way to query a paid app's price in user's currency too? (the app itself, not the in-app purchases)
+Ryan Hayle I think the biggest advantage of in-app billing is to allow free versions of application, then purchase the full featured version through in-app billing. 

In-app billing is much better in my opinion than seeing the market flooded with "free" and "pro" versions + the huge difficulty in maintain 2 separate APKs! 
+Ryan Hayle I play many games with in-app purchases and they are great even when you don't pay a dime - for example Towers&Trolls. Proper developers make games with in-app payments in such way that they are not needed to win. Do you play Angry Birds by the way - because it has in-app payments...
+Ryan Hayle Without in-app billing, Comixology becomes a larger pain-in-the-ass than most people are willing to put up with.  

In-App billing also allows for in-place upgrades or trials.

Not all apps that have in-app purchases use them for smurfberries, or some other bogus currency to drain a parent's wallet
It IS annoying to see a seemingly free app in the market only to find out when you try to use it that you have to pay for practically everything.  It sort of negates the free / pay categories in the market.
Bira Neto
Users don't want to pay for a game/app, users don't want to see ads. The average user doesn't care if you have kids or if you need the money to pay your bills. He doesn't care if you put a lot of effort on your work. If he finds your paid app cracked on fileupload dot whatever he will download it and use it. We devs need ways to monetize our work and everything that helps us in this sense is welcome.
I don't believe in proprietary, closed-source software in the first place.  I can see a potential use-case for IAP in obtaining unique content like comics, films, etc., but definitely not for software features.

+Bira Neto if you want to monetize everything, you are in the wrong field of work.  Write an app because YOU want the features it provides, not to make money off of it.  And receive the benefits of other users who have done the same.  Contribute to making the world a better place, not a more greedy and selfish one.
Bira Neto
+Ryan Hayle Explain to me again how I will buy food at the end of the month?
Nothing wrong with wanting to make money off of writing software.  It's little different than making money off of writing a book.  There's also nothing wrong with writing software for free.

I have an app that I provide for free with no limits and no advertisements.  I would like to accept donations via in-app billing, and this long-overdue simplification of the in-app billing system will probably make it worth my while to add now.  Previously it wasn't worth the heartache of trying to make work since I don't expect to get very many donations anyway.
What about managing refunds? What about subscriptions? The version 3 seems to be pretty incomplete. 
+Ryan Hayle so what do you do if you develop software for living?
does it make google wallet available for verizon galaxy nexus yet?  oh wait... that's not your fault...
Sure, right after I implement/launch the old technique they come out with the new simplified technique, figures.
omg you came out of the closet
Rob Ban
I always find it a bit scary to write code for my in-app purchases, just because I don't want to mess anything up.
I'll look into this in the future. Especially like that one can query title, description and price in the user's currency. That way the prices will always look/"be" correct to the end user.
This sounded great because I was about to implement in-app billing in one of my apps. But then I saw that subscriptions wasn't supported, which is what I need. Why make a new version that can't do what the old one did? It's great that you make it simpler, but you could just as well have waited until it was fully featured. Any idea on when subscriptions will be supported with version 3? Looks like I'll have to implement the old one first and then change.
Shoutout from Malaysian Developers: "We want to sell apps!"
I cannot put any of my videos on to youtube what the hell is going on?
I think they have to create also a new apps for the jobless people like me  so that it is easy for us  to find a job using an android apps.
Ummm scratching head hi im new here so like ummm can someone show me where the loo is......plz

Hehe..mrning All
i have the 4.1.2 on s3 thanks android
+Ryan Hayle As with every feature there is the risk of people using it wrongly. But generally, In-App Billing is a great feature which allows me to offer services without having to flood the Play Store with a second, pay-to-buy app... If you don't want to pay for an app you think that's worth it, then just don't... I personally don't have a problem doing so, because I know how much time is spent developing apps... so why not honor this?

What concerns me more are apps that put advertisements in Notifications or anything alike... but I wouldn't keep those on my phone...

But back to topic: Thank you, +Android Developers for making this much easier now!
I nearly pulled out my teeth to understand how IAB v2 works (subscriptions), now v3 is out? It's great v3 is so much easier than v2, but I really hope you guys let us know what's coming in next 6 months in advance?  Where's your developer liaison? When will v3 subscription come out? Looks like soon all my time spent on v2 learning is going to be wasted.
In-app Billing = malware. I rather see paid apps than hidden rip-offs. 
+Imar Mendoza honestly confused at how you can call in app billing malware when the market itself by definition uses in app billing which obviously are not against since it provides a way to purchase applications. That is an overly generalized statement.
+David Buxbaum as far as I know, google policy is basically "if it isn't in the public domain, then telling or hinting about something new is a dismissable offence" - which if you think about it really does simplify the whole corporate policy on who can say what when.
Doesnt seem to work, just been changing one of my apps over from v2 to v3 and get the error..
12-11 14:42:23.668: D/ACT(26101): Problem setting up In-app Billing: IabResult: Error checking for billing v3 support. (response: 3:Billing Unavailable)

Something wrong here, play store version is 3.10.9
So where is the licensing key now? It has been deleted from the old console, and the new one doesn't support multiple APK's. I don't see a way to display it? +Ellie Powers 
Instead of recommending that 'you should use a string that uniquely identifies the user' just give us the Google account of the buyer already. And no, it's not straightforward to get it via the AccountManager, because they can have multiple accounts and there is no way to know which one they are currently using for Google Play. 
And instead of doing another AIDL+Helper class, this should have 
really been integrated into Google Play Services. What's the point 
of calling it 'Google Play Services' if you can't use it to interact 
with the actual Play Store? 
Some developers make it way too easy to accidently be drunk and playing need for speed and then hit the wrong three buttons to pay EA games 50 dollars for more fake in game money. That needs to end. 
+Nikolay Elenkov I don't touch the stuff, it doesn't agree with me. What I really was referring to was something that I am currently alluding to that is green. 
This is cool but to me I'm just not ready to spend a bunch of money on in app purchases(especially games) until Google releases a application/setting that lets you back-up all app data onto there servers. Not that the developers having there own solution sometimes is bad, but to me it's like a bandaid for the problem and I would rather Google the masters behind Android handle my data. I would like a Google app/setting that lets you pick what app data to backup and restore because not all apps would need it.(example would be Google+/Facebook since it syncs directly to the web) Would be major major help since I got burned once on in app purchases when switching phones since they do not carry over to new phone in most cases and developers don't have to help you if they don't want to. Plus I would rather not have to root my phone to be in control of my app data that cost me time and money. Sorry for the rant but as you can tell I don't much care for in app purchases:-)
Downloaded 4.1 jellybean update. Now my "draw something" game doesn't work. Will there be another update soon to fix this?
Does the new version support restoreTransactions when called from within China?  The first version didn't, and so you would get a load of people visiting China and suddenly their IAPs stopped working. Note, LVL has always behaved as one would hope - i.e. fetching licensing information could also be performed from within non-paid app countries.
Meanwhile in Romania: no way of selling Android applications or In-App Billing or nothing. Google, you're a jerk.
Mathew Winters : Was the same for me. I removed the cache, data and updates for the play app, started the play app again and now it works.
Thanks Mikael, this also fixes my problem! Now lets hope that not all everyone using my app are forced to clear their Play Store cache :-D
To all developers, in your rush to monetarise your app or game, don't get caught by the backlash against the exploitation of the vulnerable. Billing of children for virtual dolls' clothing and in game cheats is not going over well with the parents when they get the bill. Such billings could destroy your product's reputation.
just check new example and its great, easy to use, simply, great work. Yes, as +Lee Shipley  mentioned, in app could be dangerous for children, but I think that PIN code for in app will be required too in future.
Mikael Alfredsson / Mark Mooibroek: I had the same error thrown at me from the startSetup() method. Clearing cache/deleting data, as suggested by Mikael, worked for me too. However, it made the Google Play store app display a screen telling me "it's now beeing updated from Android Market(!) to Google Play" and prompting for acceptance of the EULA or similar. :/

I guess people will eventually have the new versions of Google Play anyway, but at the time of writing, this an awkward situation:

"-Hey, check my new app out. You just have to clear the cache and wipe the data from the Google Play app first. Yeah, the one you use to install new Stuff from Google Play. Uh, and you'll have to accept some EULA or something before it works. No, it didn't reset your phone to it's original state, it's just some badly written information from Google. You would have got that sooner or later anyway. ... so, what do you think of my app's UX?"
+Android Developers I implement the new inappbilling version in exact the same way as it has been described on the documentation.

But after binding the service

activity.bindService(new Intent(""),
          mServiceConn, Context.BIND_AUTO_CREATE);

the IInAppBillingService mService variable is always null.

Do you have an idea what could be wrong?
lets bring in app purchase capability to eu/estonia. does google need additional local partners to make it happen?

Seems new users, not old testing accounts that have brought/cancelled the item don't need the app data/cache cleared (verified by creating new user on my Nexus 7),

BUT here is the catch.. I cancelled my order (as it was a test), and the PurchaseState is still = 0 (which is purchased) not 1 for cancelled or 2 for refunded.. and this is 12 hours later now.. have tried clearing the store data and removing-installing the app.

Anyone actually have cancelling purchases with the new system work? I would expect that if their credit card failed that would be an instant return of cancelled which should work.
The play store app was updated today, it fixes the cancel problem, after updating, opening the app showed the purchase was no-longer valid. :)
The SDK extras Billing component was also updated today. Anyone found information about what was actually updated/fixed?
It is a step in the right direction, but it does not support subscriptions for example. That means, I can't upgrade my apps to that version. I hope the next version will be out soon and be completed this time.
+Ryan Hayle No, developers don't deserve to be paid for their work, do they? Only people with REAL jobs deserve to make money right?
+Imar Mendoza Don't be so narrow minded - IN-App billing allows us to offer a 'free' and 'paid' version of an App using the same code, keeping your progress/saved games and generally making life easier for the player and the developer - it's not just about selling virtual hats and money...
Would be also interesting to know, when we will be able to change a subscription prices?
Klymentiy: I don't think we will? The customer expects to always be charged the same amount for the whole duration of the subscription, right?
+Martin Öjes Customer won't be charged extra. The price change would stop recurring payments and user will be notified about it. I would like to make some promotions in my application, like reduced prices for a couple of month, etc. It works fine in ios app store, I don't see why it can't in google play.
+Klymentiy Haykov +Martin Öjes  I think there is a better approach for changing subscription prices.

If the change is lowering the price, that would affect existing subscribers (and new subscribers of course) and their subscription will not be canceled, it will just adjust to the lower price. They should of course get an email of the change, which should be good as no one will complain about lower prices.

If the subscription price is increased, then that will affect only new subscribers and all existing subscribers will continue with the old price. Their subscription should not be automatically canceled in this case. There is nothing more frustrating about someone unexpectedly canceling your subscription, in which case you have to manually re-subscribe... and on top of that the price was increased!
Ok, I see it would be doable. But first things first - enable subscriptions in v3 at all, then improve it.
Any word on when we might see subscriptions in the new API? are we talking weeks? months? I know lots of people who are waiting for this as v3 seems to be much simpler than v2. :)
Tyler W
I implemented the v3 billing library using Google's sample code and it generates more exceptions than anything I've ever seen...

I've had to wrap almost every call in try/catch blocks and constantly check for nulls.

Anyone else had this experience with a published app?
+Tyler W I have implemented it and had the same problems with users, though eaiser to implement it has some problems on the google end, returns null from many of the calls.
How do we report bugs for this? It returns null signed data and purchase details even though billing succeeds. Seems to happen for existing apps with a draft version, but that may not be the only/definitive case. Sample app as new draft app seems to work though. 
In addition to this, today I discovered that v2 Restore Transactions does not anymore sends you receipts for expired subscriptions. Wtf, google? I still want to provide some content for users with expired subscriptions!
I really like IAB v3 So much nicer than the old one and seems to be working fine for me. Would really like some indication of when Subscriptions will be supported though, As I have a few apps that are waiting to be released because I'd rather not implement V2 then just have to upgrade a week later :/
Suggestion:  Since IAB v.3 now caches purchase data on the device, how about providing an interface that could allow each app to store a very small amount of data there (about the size of an install date would be nice) that would remain present there even if app data were cleared or if the app were uninstalled?  

Right now, if we want to implement a full-featured time-limited trial, we either have to request Internet access permission or we have to request permission to write to the permanent memory of the device, in order to store the install date.  Even apart from the possibly-otherwise-unneeded permissions, there are other problems with these approaches, and they are in any case a lot of trouble just to store a single date.  

If Google Play would hide this small cache of data inside itself for the app's eyes only, we could be confident that it would not be deleted, and also that it would be accessible regardless of current Internet connectivity or SD card availability.
Regarding cancellation of an order not showing up (as reported by Mathew Winters above), I still have that issue with a modified version of the TrivialDrive sample app (since the original version does not even test the purchase type to see if an item is there as canceled, refunded or purchased).  I went into Checkout and canceled the order that I had placed from my own test account (not the developer account) and fifteen hours later the app is still reporting a purchase type of 0 (Purchased).  This is on Nexus 7 with Google Play Store version 3.10.10.  After the fifteen hours with no change, I cleared the Google Play app's cache, stopped the TrivialDrive app and started it again.  Still no change.  Then, installed TrivialDrive for the first time ever on my Nexus One phone.  The Premium item still shows up as Purchased.  This version of the store is also 3.10.10.
Tyler W
Yeah, it generally takes 3-4 days for a cancelled purchase to show up on a device.
Bruce T
I am using V3 for subscriptions. All you have to do is consume the subscription after 30 days and notify the user the subscription is expired. Downside is the user has to re-purchse the subscription.

You can do this until V3 supports subscriptions with re-curring billing and then easily update your app.
Thanks for the great work on simplifying the billing API.  Although I canceled a purchase, it still appears as a valid purchase even the next day. This need to be fixed. At least an API call to expire the local GooglePlay cache? Thanks.
Tyler W
Immediately consume the purchase and add the currency.
InAPP Purchase Error  checking for billing V3 support (response :3:Billing  Unavailable)  in my micromax a_70
Hello Developers,
I am migrating from IAB v2 to IAB v3 and I can't purchase the same product again in the same application. I want to purchase cards. This is not consumable, nor subscription. I just want my app to be able to purchase the same card again and again. How this can be done in the IAB v3? Thank you
Is it possible for an app that uses IAB v3 to lookup a purchase made with IAB v2?  
@Ladislav Skokan:  Just add a menu item to your app for testing only that performs a consumeAsync() call (using IabHelper) on the item that you are testing, then use that menu item manually to consume the purchased item so that you will be able to buy it again for testing purposes.

My understanding is that there is no real difference, so far as the Google Play app / store are concerned, between consumable and non-consumable products.  What makes a product "consumable" is the fact that your app consumes it immediately after it is purchased, and then records whatever items were purchased within the app itself.  So if you need to test purchasing a product again and again, then even if you intend it to be non-consumable, you can call consumeAsync() on it just as if it were a consumable product, thereby resetting the purchase info so that you can buy it again.
+akash gupta I have been unable to receive confirmation of order cancellation via Checkout to my app in a reliable and timely manner.  I am presently treating this as a flaky "feature" of IAB3 on which I will not allow my app to depend.  The saving aspect of this is that (to the best of my knowledge) all refunds for IAB3 must go through the developer; i.e., the user has no way to automatically receive a refund, and so must use informal means such as email to request one from the dev.  That at least puts the dev in the loop.
+Carl Gunther I am too not getting any solution for this anywhere.
And thanks for your advice, gonna follow this.
Is anyone here able to work with the static product id's? I tried the 'android.test.purchased' in my app, and I was able to buy it. Now I cannot buy it again, so I tried consuming it, and it wont get consumed even (I get a Developer Error 5). So now I am stuck at testing this further. Is there a recommended way to continuously test with this static id?
+Ravneet Grewal Developer Error 5 is usually due to testing with an app that has not been signed with the same license as the APK that was uploaded to the Dev Console, or that has a different version code than that uploaded APK.  It is possible to consume a static product ID and that should make it available to be re-purchased.
+akash gupta I have recently discovered that re-booting a device will cause Google Play to refresh its locally-buffered data from the Google Play servers - at least in the case of detecting a purchase made on a different device owned by the same account.  It may be that changes due to cancellation or refunding of an order via Checkout could also be detected in the same manner.
hello i am having confusion that i want to implement faclity that once use buy item from my app than item will be download from my own remote server. but i don't find any document to implement this functionality .. can you help me please
Hello all. I just integrated v3 of in-app billing and it seems to work well. I just had a question though about it caching purchases on the device. I just tried turning on flight/airplane mode so that I didn't have a network connection. Now when the IabHelper.QueryInventoryFinishedListener runs I can see the following in the LogCat: IabResult: Error refreshing inventory (querying price of items). (response: 6:Error). Does that mean a device always has to have a network connection to check the inventory even though it caches purchases? Or am I misunderstanding something?
Hi guys, i manage to create in-app billing in my app and i can buy it already. the problem is, i dont get notification from google if user buy it. google never call "onActivityResult" on my app. so i cannot find out if user buy my product or not. any idea guys ?
Why is it so cumbersome to debug IAP ? 1) I can't actually debug IAP in Android Studio since the APK has to be signed and the default debug signature won't do 2) the developer account is unable to purchase anything - understandable for a release APK, but an unnecessary limitation in alpha and beta testing !
how do i be able to support the refund and does it possible to reproduce a json format to for refund?

Add a comment...