The In-app Billing Version 3 API makes it easier for you to integrate In-app Billing into your applications. The features in this version include improved synchronous purchase flow, APIs to let you easily track ownership of consumable goods, and local caching of in-app purchase data.
You define your products using the Google Play Developer Console, including product type, SKU, price, description, and so on. For more information, see Administering In-app Billing. The Version 3 API supports managed in-app products and subscriptions.
Managed in-app products are items that have their ownership information tracked and managed by Google Play. When a user purchases a managed in-app item, Google Play stores the purchase information for each item on a per-user basis. This enables you to later query Google Play at any time to restore the state of the items a specific user has purchased. This information is persistent on the Google Play servers even if the user uninstalls the application or if they change devices.
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.
A subscription is a product type offered in In-app Billing that lets you sell content, services, or features to users from inside your app with recurring monthly or annual billing. You can sell subscriptions to almost any type of digital content, from any type of app or game. To understand how subscriptions work, see In-app Billing Subscriptions.
With the Version 3 API, you can use the same purchase flow for buying subscriptions and retrieving subscription purchase information as with in-app products. For a code example, see Implementing Subscriptions.
Important: Unlike in-app products, subscriptions cannot be consumed.
A typical purchase flow with the Version 3 API is as follows:
isBillingSupportedrequest to Google Play to determine that the target version of the In-app Billing API that you are using is supported.
getPurchasesrequest. If the request is successful, Google Play returns a
Bundlecontaining a list of product IDs of the purchased items, a list of the individual purchase details, and a list of the signatures for the purchases.
getSkuDetailsrequest. You must specify a list of product IDs in the query request. If the request is successful, Google Play returns a
Bundlecontaining product details including the product’s price, title, description, and the purchase type.
getBuyIntentrequest, specifying the product ID of the item to purchase, along with other parameters. You should record the product ID when you create a new in-app product in the Developer Console.
Bundlethat contains a
PendingIntentwhich your application uses to start the checkout UI for the purchase.
onActivityResultmethod. The result code of the
onActivityResulthas a result code that indicates whether the purchase was successful or canceled. The response
Intentcontains information about the purchased item, including a
purchaseTokenString that is generated by Google Play to uniquely identify this purchase transaction. The
Intentalso contains the signature of the purchase, signed with your private developer key.
To learn more about the Version 3 API calls and server responses, see In-app Billing Reference.
You can use the consumption mechanism to track the user's ownership of in-app products.
In Version 3, all in-app products are managed. This means that the user's ownership of all in-app item purchases is maintained by Google Play, and your application can query the user's purchase information when needed. When the user successfully purchases an in-app product, that purchase is recorded in Google Play. Once an in-app product is purchased, it is considered to be "owned". In-app products in the "owned" state cannot be purchased from Google Play. You must send a consumption request for the "owned" in-app product before Google Play makes it available for purchase again. Consuming the in-app product reverts it to the "unowned" state, and discards the previous purchase data.
To retrieve the list of product's owned by the user, your application sends a
getPurchases call to Google Play. Your application can make a
consumption request by sending a
consumePurchase call. In the request
argument, you must specify the in-app product's unique
String that you obtained from Google Play when it was purchased. Google Play
returns a status code indicating if the consumption was recorded
It's up to you to decide if you want to handle your in-app products as non-consumable or consumable items.
Important: Before provisioning the consumable in-app product in your application, you must send a consumption request to Google Play and receive a successful response indicating that the consumption was recorded.
Here is the basic flow for purchasing a consumable in-app product:
Bundlefrom Google Play indicating if the purchase completed successfully.
Subsequently, when the user starts up or logs in to your application, you should check if the user owns any outstanding consumable in-app products; if so, make sure to consume and provision those items. Here's the recommended application startup flow if you implement consumable in-app products in your application:
getPurchasesrequest to query the owned in-app products for the user.
consumePurchase. This step is necessary because the application might have completed the purchase order for the consumable item, but stopped or got disconnected before the application had the chance to send a consumption request.
Because the Google Play client now caches In-app Billing information locally
on the device, you can use the Version 3 API to query for this information
more frequently, for example through a
getPurchases call. Unlike with
previous versions of the API, many Version 3 API calls will be serviced
through cache lookups instead of through a network connection to Google Play,
which significantly speeds up the API's response time.