Develop Reference

Same In-App product shared among multiple apps (Android)

Is it possible to have the same in-app product(managed) in multiple apps? Such that if a user buys a premium upgrade in one of the apps, he gets premium upgrade in all of them.
Note that I'm not planning to maintain a user database currently and trying to find a solution using Google's in-app billing API alone if it's possible.

No, it's not possible, unless you build your own database. Entitlements are always related to an app (package name), which means if a user buys a SKU of App A, the Play Billing library can only pull entitlements for App A from its code.

Per Device subscriptions for purchases through Google Play

I would like to setup subscription based billing for an app that will be sold through Google Play. Is it possible to sell the same subscription to the same user but on a different devices? So that every device that user tries to use the app on would need an active subscription?
I was thinking I could store the device id and user id on my own server and authenticate it that way, but is it correct that a user can't purchase the same subscription more than once? So would I need a pool of basically the same subscriptions if the user wishes to purchase multiple "licenses"? Can Google Play Billing handle any of this natively?
Thanks

The documentation from Google initially seems to make this impossible to achieve but digging deeper, I uncovered the following...
In the Google Play API version 2.0, you could create what was called an "unmanaged" product type that allowed the user to purchase the same thing multiple times. That seems to have partly disappeared in API 3.0 although the Gooogle Developer Console clearly supports this. I assume it's still supported because apps that used the 2.0 API are still out there and Google just can't drop support for that.
In 3.0 however, the "unmanaged" product type is not listed in the API docs but the docs state the following about making multiple purchases for the same product type (one-time purchase or subscription):
If you are using the Version 3 API, you can also consume managed items
within your application. You would typically implement consumption for
items that can be purchased multiple times (such as in-game currency,
fuel, or magic spells). Once purchased, a managed item cannot be
purchased again until you consume the item, by sending a consumption
request to Google Play. To learn more about in-app product consumption,
see Consuming Items
http://developer.android.com/google/play/billing/api.html#consume
IMPORTANT: Subscriptions CANNOT be consumed which means that if you want the customer to periodically renew their license, you will have to contact them and tell them that they must purchase the license again. That's a downside if your service requires a periodic renewal.
To obtain what you are after, you will need a backend server to handle the registration of devices and store tokens the apps receive from Google Play when purchasing. When a user wants to purchase your license, feature, service (or whatever) from another device, the other device MUST first release its "ownership" of the product with Google Play, through a process known as "consuming". It would work something more or less like this:
The first device makes a purchase and receives a purchaseToken
string from Google Play.
The purchaseToken along with the device ID is sent from the app to your server and stored.
The user goes to the second device and wants to purchase the license as well for that device. The app first needs to go to your server and obtain the purchaseToken (that the first device uploaded) and then call Google Play with consumePurchase which releases the "ownership" of the product from the user.
The app then purchases the new license (or whatever) from Google Play, gets a new purchaseToken and stores it on your server along with its device ID.
In essence, Google Play won't keep track of which device has the product. It only associates the Google Account with the product being purchased. It's up to your app and server to manage the licenses.
There is one potential problem I see that you need to address. If for some reason the app fails to send the purchaseToken back to your server (your server is down, the user dropped their device and broke it, your app crashes before it saves the token on the device, etc.), then you may not know if the user paid for the service. Google does provide a server API that lets your backend server query Google Play on Google's server for information about purchases, but I'm not familiar with it nor its limitations.

You will need to implement in app purchases as you would for any other in app item.
Make sure when you create your item in the Dev Console, it is unmanaged, as managed items can only be purchased once per account.
When you receive a confirmation on purchase of your unmanaged item, send the details like the unique ID to your server and store them there.
Now whenever your app starts, check with your server if it is an authorized device. If it isn't, prompt the user to buy it. If it is, let them continue to the app.
This only works if you need a one time payment. If you need a subscription, you will have to make it up of multiple one time payments, as subscriptions are like managed purchases and can only be paid for once by any account.

Does In App Billing support multiple accounts?

Does InApp billing (V2 or V3) works for a user who uses several accounts and makes the purchase with an account that isn't the primary one?
PD: Some explanation required, no simple Yes/No

In App Billing support multiple accounts reported as a bug in code.google, have a look at it
According to Mr.Sergej (posted in G+ android dev community) in-app products purchased with the first account won't be active anymore while using multiple user accounts!.

InApp billing just charges the user and tells your app whether it was successful or not. It is up to you to figure out how to give the user what they purchased.
You can...
toggle the SharedPreferences of the app to save their purchase. Obviously multiple people can use the same app on the same device with the purchase.
provide login functionality to save a purchase to a server, in case the user deletes the app or gets a new device.
Use one-time purchases to check whether the user has purchased previously. This won't carry over to several accounts on different devices/multiple-accounts-per-device.

Android In-App Billing Dynamic Product List

I am currently working a setup for in-app billing on one of my applications. Is there a way to set up purchases without a product list on the Android Market side? Essentially, I want to do what I am allowed to do in most other merchant APIs, send the product name/id/PRICE/etc to the merchant and get back a response from them if the payment went through or not.
I have too many products to manually add each item to the Android Market Publishing area and want to send the user to the in app market request with a custom title, description, and price (most important), and have Android handle that.
Any ideas?

No you can't.
The reason for this is security. Someone could hack your app and add a new product/ change your product prices, but defining them on the market; they would have to hack your app and have your login for the android market.

In-App Billing Security and Design questions

I have a few questions connected to Android In-App Billing:
Is it possible to make a purchase from non-Market app? I understand that it would be a vulnerability, but I have no opportunity to find out if it's possible or not.
How can I get purchase state for a particular product? As far as I understand it can be done using RESTORE_TRANSACTIONS request, but it's not recommended to use very often. That's not a theoretical problem. My application allows users to buy content using in-app billing. Content can be downloaded from a server, and server must allow content downloading only if it was purchased. But it can't check if content was purchased or not without using signed response from Android Market.
How can I get price and description of an item from Android Market? Seems that I know the answer and it's "there's no way it can be done", but maybe I'm wrong. It would be very useful to have a possibility of retrieving item's price.
It's very interesting to me how you solved/are going to solve these problems in your apps. Answer to any of these questions will be appreciated.

In order:
1- Nope. The in-app billing process is part of Market. If the app comes from elsewhere, there's no way for Market to verify the origin/authenticity of the application.
2- It's your responsibility to store the purchase state for a particular product. From the doc:
You must set up a database or some other mechanism for storing users' purchase information.
RESTORE_TRANSACTIONS should be reserved for reinstalls or first-time installs on a device.
3- Unfortunately, at this time you're right. File a feature request!
In the meantime, one option is to set up a website with appengine, store listings of all your content & pricing there, and then manually sync prices listed on your appengine server with the updated prices in Market. Then have your Android app pull the data from the AppEngine server. This is much better than hardcoding price values into the app itself, since you don't need to have everyone update the app immediately to see accurate pricing whenever you change something. The only caveat of this method is that if the user is in a different country, in-app billing will display an approximated price in their native currency, and there's no way for you to determine exactly what price will be displayed to them.
Related, One of the Android Developer Advocates is giving a talk on LVL/IAP at IO, called "Evading Pirates and Stopping Vampires using License Verification Library, In-App Billing, and App Engine." - It would definitely be worth your while to watch when they release the session videos on the website.