From 8dcc99dd82047c43f432ec6073c04bbe59c81e09 Mon Sep 17 00:00:00 2001
From: quddusc 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 only supports the managed in-app product type.Product Types
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.
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 item, that purchase is recorded in Google Play. Once an item is purchased, it is considered to be "owned". Items in the "owned" state cannot be purchased from Google Play. You must send a consumption request for the "owned" item before Google Play makes it available for purchase again. Consuming the item reverts it to the "unowned" state, and discards the previous purchase data.
+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.
Figure 2. The basic sequence for a consumption request.
To retrieve the list of product's owned by the user, your application sends a {@code getPurchases} call to Google Play. Your application can make a consumption request by sending a {@code consumePurchase} call. In the request argument, you must specify the item's unique {@code purchaseToken} String that you obtained from Google Play when it was purchased. Google Play returns a status code indicating if the consumption was recorded successfully.
+To retrieve the list of product's owned by the user, your application sends a {@code getPurchases} call to Google Play. Your application can make a consumption request by sending a {@code consumePurchase} call. In the request argument, you must specify the in-app product's unique {@code purchaseToken} String that you obtained from Google Play when it was purchased. Google Play returns a status code indicating if the consumption was recorded successfully.
-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 item in your application, you must send a consumption request to Google Play and receive a successful response indicating that the consumption was recorded.
+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 item:
+Here is the basic flow for purchasing a consumable in-app product:
Subsequently, when the user starts up or logs in to your application, you should check if the user owns any outstanding consumable items; if so, make sure to consume and provision those items. Here's the recommended application startup flow if you implement consumable items in your application:
+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:
To start a purchase request from your app, call the {@code getBuyIntent} method on the In-app Billing service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, the product ID for the item to purchase, the purchase type (“inapp”), and a {@code developerPayload} String. The {@code developerPayload} String is used to specify any additional arguments that you want Google Play to send back along with the purchase information.
+To start a purchase request from your app, call the {@code getBuyIntent} method on the In-app Billing service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, the product ID for the item to purchase, the purchase type (“inapp” or "subs"), and a {@code developerPayload} String. The {@code developerPayload} String is used to specify any additional arguments that you want Google Play to send back along with the purchase information.
Bundle buyIntentBundle = mService.getBuyIntent(3, getPackageName(),
@@ -238,7 +239,7 @@ protected void onActivityResult(int requestCode, int resultCode, Intent data) {
Security Recommendation: When you send a purchase request, create a String token that uniquely identifies this purchase request and include this token in the {@code developerPayload}.You can use a randomly generated string as the token. When you receive the purchase response from Google Play, make sure to check the returned data signature, the {@code orderId}, and the {@code developerPayload} String. For added security, you should perform the checking on your own secure server. Make sure to verify that the {@code orderId} is a unique value that you have not previously processed, and the {@code developerPayload} String matches the token that you sent previously with the purchase request.
Querying for Purchased Items
-To retrieve information about purchases made by a user from your app, call the {@code getPurchases} method on the In-app Billing Version 3 service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, and the purchase type (“inapp”).
+To retrieve information about purchases made by a user from your app, call the {@code getPurchases} method on the In-app Billing Version 3 service. Pass in to the method the In-app Billing API version (“3”), the package name of your calling app, and the purchase type (“inapp” or "subs").
Bundle ownedItems = mService.getPurchases(3, getPackageName(), "inapp", null);
@@ -273,8 +274,26 @@ if (response == 0) {
You can use the In-app Billing Version 3 API to track the ownership of purchased items in Google Play. Once an item is purchased, it is considered to be "owned" and cannot be purchased from Google Play. You must send a consumption request for the item before Google Play makes it available for purchase again. All managed in-app products are consumable. How you use the consumption mechanism in your app is up to you. Typically, you would implement consumption for products with temporary benefits that users may want to purchase multiple times (for example, in-game currency or equipment). You would typically not want to implement consumption for products that are purchased once and provide a permanent effect (for example, a premium upgrade).
-To record a purchase consumption, send the {@code consumePurchase} method to the In-app Billing service and pass in the {@code purchaseToken} String value that identifies the purchase to be removed. The {@code purchaseToken} is part of the data returned in the {@code INAPP_PURCHASE_DATA} String by the Google Play service following a successful purchase request. In this example, you are recording the consumption of a product that is identified with the {@code purchaseToken} in the {@code token} variable.
+You can use the In-app Billing Version 3 API to track the ownership of +purchased in-app products in Google Play. Once an in-app product is purchased, +it is considered to be "owned" and cannot be purchased from Google Play. You +must send a consumption request for the in-app product before Google Play makes +it available for purchase again.
+Important: Managed in-app products are +consumable, but subscriptions are not.
+How you use the consumption mechanism in your app is up to you. Typically, +you would implement consumption for in-app products with temporary benefits that +users may want to purchase multiple times (for example, in-game currency or +equipment). You would typically not want to implement consumption for in-app +products that are purchased once and provide a permanent effect (for example, +a premium upgrade).
+To record a purchase consumption, send the {@code consumePurchase} method to +the In-app Billing service and pass in the {@code purchaseToken} String value +that identifies the purchase to be removed. The {@code purchaseToken} is part +of the data returned in the {@code INAPP_PURCHASE_DATA} String by the Google +Play service following a successful purchase request. In this example, you are +recording the consumption of a product that is identified with the +{@code purchaseToken} in the {@code token} variable.
int response = mService.consumePurchase(3, getPackageName(), token);@@ -282,6 +301,33 @@ int response = mService.consumePurchase(3, getPackageName(), token);
It's your responsibility to control and track how the in-app product is provisioned to the user. For example, if the user purchased in-game currency, you should update the player's inventory with the amount of currency purchased.
Security Recommendation: You must send a consumption request before provisioning the benefit of the consumable in-app purchase to the user. Make sure that you have received a successful consumption response from Google Play before you provision the item.
+Launching a purchase flow for a subscription is similar to launching the +purchase flow for a product, with the exception that the product type must be set +to "subs". The purchase result is delivered to your Activity's +{@link android.app.Activity#onActivityResult onActivityResult} method, exactly +as in the case of in-app products.
+
+Bundle bundle = mService.getBuyIntent(3, "com.example.myapp",
+ MY_SKU, "subs", developerPayload);
+
+PendingIntent pendingIntent = bundle.getParcelable(RESPONSE_BUY_INTENT);
+if (bundle.getInt(RESPONSE_CODE) == BILLING_RESPONSE_RESULT_OK) {
+ // Start purchase flow (this brings up the Google Play UI).
+ // Result will be delivered through onActivityResult().
+ startIntentSenderForResult(pendingIntent, RC_BUY, new Intent(),
+ Integer.valueOf(0), Integer.valueOf(0), Integer.valueOf(0));
+}
+
+To query for active subscriptions, use the {@code getPurchases} method, again +with the product type parameter set to "subs".
++Bundle activeSubs = mService.getPurchases(3, "com.example.myapp", + "subs", continueToken); ++
The call returns a {@code Bundle} with all the active subscriptions owned by +the user. Once a subscription expires without renewal, it will no longer appear +in the returned {@code Bundle}.
diff --git a/docs/html/google/play/billing/billing_overview.jd b/docs/html/google/play/billing/billing_overview.jd index aa48fc8195f7c..bda9237774baa 100755 --- a/docs/html/google/play/billing/billing_overview.jd +++ b/docs/html/google/play/billing/billing_overview.jd @@ -7,9 +7,12 @@ parent.link=index.htmlCurrently, Google Play supports two versions of the In-app Billing API. -To determine which version you should use, see Migration -Considerations.
-In-app billing Version 3 is the latest version, and maintains very broad +compatibility across the range of Android devices. In-app Billing Version 3 is +supported on devices running Android 2.2 or higher that have the latest version +of the Google Play store installed (a vast majority of active devices).
+ +Both versions offer very broad compatibility across the range of Android -devices. In-app Billing Version 3 is supported on devices running Android 2.2 or -higher that have the latest version of the Google Play store installed -(over 90% of active devices). Version 2 offers similar compatibility. See -Version Notes for -more details.
+For details about other versions of In-app Billing, see the +Version Notes.
In-app products are the digital goods that you offer for sale from inside your @@ -102,12 +94,9 @@ published for another app, even if they are from the same developer.
how you monetize your application. In all cases, you define your products using the Google Play Developer Console.You can specify these types of products for your In-app Billing application -— managed in-app products, subscriptions, and unmanaged -in-app products. The term “managed” indicates that Google Play handles and -tracks ownership for in-app products on your application on a per user account -basis, while “unmanaged” indicates that you will manage the ownership information yourself.
-To learn more about the product types supported by the different API versions, -see the related documentation for Version 2 and Version 3.
+— managed in-app products and subscriptions. Google Play +handles and tracks ownership for in-app products and subscriptions on your +application on a per user account basis. Learn more about the product types supported by In-app Billing Version 3.The Developer Console is where you can publish your @@ -148,70 +137,31 @@ providing the checkout user interface (middle screen). When checkout is complete, the application resumes.
-To help you integrate In-app Billing into your application, the Android SDK -provides two sample applications that demonstrate how to sell in-app products +provides a sample application that demonstrates how to sell in-app products and subscriptions from inside an app.
-The TrivialDrive sample for the Version 3 API sample shows how to use the In-app Billing Version 3 API +to implement in-app product and subscription purchases for a driving game. The +application demonstrates how to send In-app Billing requests, and handle +synchronous responses from Google Play. The application also shows how to record +item consumption with the API. The Version 3 sample includes convenience classes +for processing In-app Billing operations as well as perform automatic signature +verification.
-Important: It's strongly recommended -that you obfuscate the code in your application before you publish it. For -more information, see +
Recommendation: Make sure to obfuscate the +code in your application before you publish it. For more information, see Security and Design.
The following considerations may be applicable if you are planning to create a new -in-app biling application, or migrate your existing In-app Billing implementation -from the Version 2 or -earlier API to the Version 3 API.
-Google Play will continue to support both the Version 2 and Version 3 APIs for -some time, so you can plan to migrate to Version 3 at your own pace. The Google -Play team will give advance notice of any upcoming changes to the support -status of In-app Billing Version 2.
-You can use the following table to decide which version of the API to use, -depending on the needs of your application.
-- Table 1. Selecting the In-app Billing API Version for Your -Project
+If you have an existing In-app Billing implementation that uses Version 2 or +earlier, it is strongly recommended that you migrate to In-app Billing Version 3 at your earliest convenience.
-| Choose Version 3 if ... | -Choose Version 2 if ... | -
|---|---|
-
|
-
-
|
-
If you have published apps selling in-app products, note that:
Subscriptions let you sell content, services, or features in your app with +automated, recurring billing. You can easily adapt an existing In-app Billing +implementation to sell subscriptions.
+This document is focused on highlighting implementation details that are +specific to subscriptions, along with some strategies for the associated billing +and business models.
+ +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.
+ +As with other in-app products, you configure and publish subscriptions using +the Developer Console and then sell them from inside apps installed on +Android devices. In the Developer console, you create subscription +products and add them to a product list, then set a price and optional trial +period for each, choose a billing interval (monthly or annual), and then +publish. For more information about using the Developer Console, see +Configuring Subscription Items.
+ +When users purchase subscriptions in your apps, Google Play handles all +checkout details so your apps never have to directly process any financial +transactions. Google Play processes all payments for subscriptions through +Google Checkout, just as it does for standard in-app products and app purchases. +This ensures a consistent and familiar purchase flow for your users.
+ +
+
+After users have purchase subscriptions, they can view the subscriptions and +cancel them from the My Apps screen in the Play Store app or +from the app's product details page in the Play Store app. For more information +about handling user cancellations, see Subscription Cancellation.
+ +In adddition to client-side API calls, you can use the server-side API for +In-app Billing to provide subscription purchasers with extended access to +content (for example, from your web site or another service). +The server-side API lets you validate the status of a subscription when users +sign into your other services. For more information about the API, see Google Play Android Developer API.
+ +You can also build on your existing external subscriber base from inside your +Android apps.
+In general the same basic policies and terms apply to subscriptions as to +standard in-app products, however there are some differences. For complete +information about the current policies and terms, please read the policies document.
+ +To learn about the minimum system requirements for +subscriptions, see the Version Notes.
+ +To create and manage subscriptions, use the Developer Console to set up a +product list for the app then configure these attributes for each subscription +product:
+ +For details on how to add and configure products in the Developer Console, +see Administering +In-app Billing.
+ +When you create a subscription in the Developer Console, you can set a price +for it in any available currencies. Each subscription must have a non-zero +price. You can price multiple subscriptions for the same content differently +— for example you could offer a discount on an annual subscription +relative to the monthly equivalent.
+ +Important: To change the price of a +subscription, you can publish a new subscription product ID at a new price, +then offer it in your app instead of the original product. Users who have +already purchased will continue to be charged at the +original price, but new users will be charged at the new price.
+ +In the Developer Console, you can configure subscription products with +automated recurring billing at either of two intervals:
+ +Billing continues indefinitely at the interval and price specified for the +subscription. At each subscription renewal, Google Play charges the user account +automatically, then notifies the user of the charges afterward by email. Billing +cycles will always match subscription cycles, based on the purchase date.
+ +Over the life of a subscription, the form of payment billed remains the same +— Google Play always bills the same form of payment (such as credit card +or by Direct Carrier Billing) that was originally used to purchase the +subscription.
+ +When the subscription payment is approved by Google Checkout, Google Play +provides a purchase token back to the purchasing app through the In-app Billing +API. Your apps can store the token locally or pass it to your backend servers, +which can then use it to validate or cancel the subscription remotely using the Google Play Android Developer API.
+ +If a recurring payment fails (for example, because the customer’s credit +card has become invalid), the subscription does not renew. How your app is +notified depends on the In-app Billing API version that you are using:
+Recommendation: Include business logic in your +app to notify your backend servers of subscription purchases, tokens, and any +billing errors that may occur. Your backend servers can use the server-side API +to query and update your records and follow up with customers directly, if needed.
+ +In the Developer Console, you can set up a free trial period that lets users +try your subscription content before buying it. The trial period runs for the +period of time that you set and then automatically converts to a full +subscription managed according to the subscription's billing interval and +price.
+ +To take advantage of a free trial, a user must "purchase" the full +subscription through the standard In-app Billing flow, providing a valid form of +payment to use for billing and completing the normal purchase transaction. +However, the user is not charged any money, since the initial period corresponds +to the free trial. Instead, Google Play records a transaction of $0.00 and the +subscription is marked as purchased for the duration of the trial period or +until cancellation. When the transaction is complete, Google Play notifies users +by email that they have purchased a subscription that includes a free trial +period and that the initial charge was $0.00.
+ +When the trial period ends, Google Play automatically initiates billing +against the credit card that the user provided during the initial purchase, at +the amount set +for the full subscription, and continuing at the subscription interval. If +necessary, the user can cancel the subscription at any time during the trial +period. In this case, Google Play marks the subscription as expired immediately, +rather than waiting until the end of the trial period. The user has not +paid for the trial period and so is not entitled to continued access after +cancellation.
+ +You can set up a trial period for a subscription in the Developer Console, +without needing to modify or update your APK. Just locate and edit the +subscription in your product list, set a valid number of days for the trial +(must be 7 days or longer), and publish. You can change the period any time, +although note that Google Play does not apply the change to users who have +already "purchased" a trial period for the subscription. Only new subscription +purchases will use the updated trial period. You can create one free trial +period per subscription product.
+ +When you have finished configuring your subscription product details in the +Developer Console, you can publish the subscription in the app product list.
+ +In the product list, you can add subscriptions, in-app products, or both. You +can add multiple subscriptions that give access to different content or +services, or you can add multiple subscriptions that give access to the same +content but for different intervals or different prices, such as for a +promotion. For example, a news outlet might decide to offer both monthly and +annual subscriptions to the same content, with annual having a discount. You can +also offer in-app purchase equivalents for subscription products, to ensure that +your content is available to users of older devices that do not support +subscriptions.
+ +After you add a subscription or in-app product to the product list, you must +publish the product before Google Play can make it available for purchase. Note +that you must also publish the app itself before Google Play will make the +products available for purchase inside the app.
+ +Important: You can remove the subscription +product from the product list offered in your app to prevent users from seeing +or purchasing it.
+ +Users can view the status of all of their subscriptions and cancel them if +necessary from the My Apps screen in the Play Store app. +Currently, the In-app Billing API does not provide support for programatically +canceling subscriptions from inside the purchasing app.
+ +When the user cancels a subscription, Google Play does not offer a refund for +the current billing cycle. Instead, it allows the user to have access to the +cancelled subscription until the end of the current billing cycle, at which time +it terminates the subscription. For example, if a user purchases a monthly +subscription and cancels it on the 15th day of the cycle, Google Play will +consider the subscription valid until the end of the 30th day (or other day, +depending on the month).
+ +In some cases, the user may contact you directly to request cancellation of a +subscription. In this and similar cases, you can use the server-side API to +query and directly cancel the user’s subscription from your servers. + +
Important: In all cases, you must continue +to offer the content that your subscribers have purchased through their +subscriptions, for as long any users are able to access it. That is, you must +not remove any subscriber’s content while any user still has an active +subscription to it, even if that subscription will terminate at the end of the +current billing cycle. Removing content that a subscriber is entitled to access +will result in penalties. Please see the policies document for more information.
+ +When the user uninstalls an app that includes purchased subscriptions, the +Play Store app will notify the user that there are active subscriptions. If the +user chooses to continue with the uninstallation, the app is removed and the +subscriptions remain active and recurring billing continues. The user can return +to cancel the associated subscriptions at any time in the My Apps +screen of the Play Store app. If the user chooses to cancel the uninstallation, +the app and subscriptions remain as they were.
+ +With subscriptions, Google Play does not provide a refund window, so users +will need to contact you directly to request a refund. + +
If you receive requests for refunds, you can use the server-side API to +cancel the subscription or verify that it is already cancelled. However, keep in +mind that Google Play considers cancelled subscriptions valid until the end of +their current billing cycles, so even if you grant a refund and cancel the +subscription, the user will still have access to the content. + +
Important: Partial refunds for canceled +subscriptions are not available at this time.
+ +In general, the terms of Google Play allow you to sell in-app subscriptions +only through the standard payment processor, Google Checkout. For purchases of +any subscription products, the transaction fee is the same as the transaction +fee for application purchases (30%).
+ +Apps published on Google Play that are selling subscriptions must use In-app +Billing to handle the transaction and may not provide links to a purchase flow +outside of the app and Google Play (such as to a web site).
+ +For complete details about terms and policies, see the policies +document.
+ +To help you track transactions relating to a given subscription, Google +Checkout provides a base Merchant Order Number for all recurrences of the +subscription and denotes +each recurring transaction by appending an integer as follows:
+ +12999556515565155651.5565135565155651 (base order number)
+12999556515565155651.5565135565155651..0 (initial purchase orderID)
+12999556515565155651.5565135565155651..1 (first recurrence orderID)
+12999556515565155651.5565135565155651..2 (second recurrence orderID)
+...
Google Play provides the order number as the value of the +{@code orderId} field of the {@code INAPP_PURCHASE_DATA} JSON field (in V3) +or the {@code PURCHASE_STATE_CHANGED} intent (in V2).
+ +Google Play offers an HTTP-based API that you can use to remotely query the +validity of a specific subscription at any time or cancel a subscription. The +API is designed to be used from your backend servers as a way of securely +managing subscriptions, as well as extending and integrating subscriptions with +other services.
+ +To use the API, you must first register a project at the Google APIs Console and receive +a Client ID and shared secret that your app will present when calling the +Google Play Android Developer API. All calls to the API are authenticated with +OAuth 2.0.
+ +Once your app is registered, you can access the API directly, using standard +HTTP methods to retrieve and manipulate resources, or you can use the Google +APIs Client Libraries, which are extended to support the API.
+ +The Google Play Android Developer API is built on a RESTful design that uses +HTTP and JSON, so any standard web stack can send requests and parse the +responses. However, if you don’t want to send HTTP requests and parse responses +manually, you can access the API using the client libraries, which provide +better language integration, improved security, and support for making calls +that require user authorization.
+ +For more information about the API and how to access it through the Google +APIs Client Libraries, see the documentation at:
+ +https://developers. +google.com/android-publisher/v1/
+ +Applications using the Google Play Android Developer API are limited to an +initial courtesy usage quota of 15000 requests per day (per +application). This should provide enough access for normal +subscription-validation needs, assuming that you follow the recommendation in +this section.
+ +If you need to request a higher limit for your application, please use the +“Request more” link in the Google APIs Console. +Also, please read the section below on design best practices for minimizing your +use of the API.
+ +Calls to the Google Play Android Developer API require authorization. Google +uses the OAuth 2.0 protocol to allow authorized applications to access user +data. To learn more, see Authorization +in the Google Play Android Developer API documentation.
+ +Access to the Google Play Android Developer API is regulated to help ensure a +high-performance environment for all applications that use it. While you can +request a higher daily quota for your application, we highly recommend that you +minimize your access using the technique(s) below.
+ +By following those general guidelines, your implementation will offer the +best possible performance for users and minimize use of the Google Play Android +Developer API.
+ + diff --git a/docs/html/google/play/billing/index.jd b/docs/html/google/play/billing/index.jd index b0d1d13f3776f..44aa00191e269 100755 --- a/docs/html/google/play/billing/index.jd +++ b/docs/html/google/play/billing/index.jd @@ -10,8 +10,8 @@ and features, and more. You can use In-app Billing to sell products asAny application that you publish through Google Play can implement In-app Billing. No special -account or registration is required other than an Android Market publisher account and a Google +account or registration is required other than a Google Play Developer Console account and a Google Checkout merchant account.
To help you integrate in-app billing into your application, the Android SDK diff --git a/docs/html/google/play/billing/v2/api.jd b/docs/html/google/play/billing/v2/api.jd index 6b3b7585c2cb6..9d3a045fa70b7 100644 --- a/docs/html/google/play/billing/v2/api.jd +++ b/docs/html/google/play/billing/v2/api.jd @@ -39,15 +39,6 @@ Version 2, rather than Version 3.
If you do not need to sell subscriptions, you should implement In-app Billing Version 3 instead.
-Free trials—You can now offer users a configurable free trial period for - your in-app subscriptions. You can set up trials with a simple change in the Developer - Console—no change to your app code is needed.
-In-app Billing Version supports three different product types diff --git a/docs/html/google/play/billing/v2/billing_subscriptions.jd b/docs/html/google/play/billing/v2/billing_subscriptions.jd index 82a662fc84fd0..5e3bd2859a4a6 100755 --- a/docs/html/google/play/billing/v2/billing_subscriptions.jd +++ b/docs/html/google/play/billing/v2/billing_subscriptions.jd @@ -1,4 +1,4 @@ -page.title=Subscriptions (IAB Version 2) +page.title=Implementing Subscriptions (IAB Version 2) @jd:body
Important: This documentation describes how to implement subscriptions with the Version 2 API. Subscription support for the in-app billing Version 3 API is coming soon.
+This document is focused on highlighting implementation details that are +specific to subscriptions with the Version 2 API. To understand how +subscriptions work, see In-app Billing Subscriptions.
-Subscriptions let you sell content, services, or features in your app with -automated, recurring billing. Adding support for subscriptions is -straightforward and you can easily adapt an existing In-app Billing -implementation to sell subscriptions.
-If you have already implemented In-app Billing for one-time purchase -products, you will find that you can add support for subscriptions with minimal -impact on your code. If you are new to In-app Billing, you can implement -subscriptions using the standard communication model, data structures, and user -interactions as for other in-app products.subscriptions. Because the -implementation of subscriptions follows the same path as for other in-app -products, details are provided outside of this document, starting with the In-app Billing -Overview.
- -This document is focused on highlighting implementation details that are -specific to subscriptions, along with some strategies for the associated billing -and business models.
- -Note: Subscriptions are supported in In-app Billing Version 2 only. Support for subscriptions will be added to Version 3 in the weeks ahead.
- -A subscription is a new 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.
- -As with other in-app products, you configure and publish subscriptions using -the Developer Console and then sell them from inside apps installed on an -Android-powered devices. In the Developer console, you create subscription -products and add them to a product list, then set a price and optional trial -period for each, choose a billing interval (monthly or annual), and then publish.
- -In your apps, it’s -straightforward to add support for subscription purchases. The implementation -extends the standard In-app Billing API to support a new product type but uses -the same communication model, data structures, and user interactions as for -other in-app products.
- -When users purchase subscriptions in your apps, Google Play handles all -checkout details so your apps never have to directly process any financial -transactions. Google Play processes all payments for subscriptions through -Google Checkout, just as it does for standard in-app products and app purchases. -This ensures a consistent and familiar purchase flow for your users.
- -
-
-
-After users have purchase subscriptions, they can view the subscriptions and -cancel them, if necessary, from the My Apps screen in the Play Store app or -from the app's product details page in the Play Store app.
- - - -Once users have purchased a subscription through In-app Billing, you can -easily give them extended access to additional content on your web site (or -other service) through the use of a server-side API provided for In-app Billing. -The server-side API lets you validate the status of a subscription when users -sign into your other services. For more information about the API, see Google Play Android Developer API, below.
- -You can also build on your existing external subscriber base from inside your -Android apps. If you sell subscriptions on a web site, for example, you can add -your own business logic to your Android app to determine whether the user has -already purchased a subscription elsewhere, then allow access to your content if -so or offer a subscription purchase from Google Play if not.
- -With the flexibility of In-app Billing, you can even implement your own -solution for sharing subscriptions across as many different apps or products as -you want. For example, you could sell a subscription that gives a subscriber -access to an entire collection of apps, games, or other content for a monthly or -annual fee. To implement this solution, you could add your own business logic to -your app to determine whether the user has already purchased a given -subscription and if so, allow access to your content.
- -In general the same basic policies and terms apply to subscriptions as to -standard in-app products, however there are some differences. For complete -information about the current policies and terms, please read the policies document.
- - -To sell a subscription in an app, you use the tools in the Developer Console -to set up a product list for the app and then create and configure a new -subscription. In the subscription, you set the price and billing interval and -define a subscription ID, title, and description. When you are ready, you can -then publish the subscription in the app product list.
- -In the product list, you can add subscriptions, in-app products, or both. You -can add multiple subscriptions that give access to different content or -services, or you can add multiple subscriptions that give access to the same -content but for different intervals or different prices, such as for a -promotion. For example, a news outlet might decide to offer both monthly and -annual subscriptions to the same content, with annual having a discount. You can -also offer in-app purchase equivalents for subscription products, to ensure that -your content is available to users of older devices that do not support -subscriptions.
- -After you add a subscription or in-app product to the product list, you must -publish the product before Google Play can make it available for purchase. Note -that you must also publish the app itself before Google Play will make the -products available for purchase inside the app.
- -Important: At this time, the capability to -unpublish a subscription is not available. Support for unpublishing a -subscription is coming to the Developer Console in the weeks ahead, so this is a -temporary limitation. In the short term, instead of unpublishing, -you can remove the subscription product from the product list offered in your -app to prevent users from seeing or purchasing it.
- -When you create a subscription in the Developer Console, you can set a price -for it in any available currencies. Each subscription must have a non-zero -price. You can price multiple subscriptions for the same content differently -— for example you could offer a discount on an annual subscription -relative to the monthly equivalent.
- -Important: At this time, once you publish a -subscription product, you cannot change its price in any currency. Support for -changing the price of published subscriptions is coming to the Developer Console -in the weeks ahead. In the short term, you can work around this limitation by -publishing a new subscription product ID at a new price, then offer it in your -app instead of the original product. Users who have already purchased will -continue to be charged at the original price, but new users will be charged at -the new price.
- -You can sell subscription products with automated recurring billing at -either of two intervals:
- -Billing continues indefinitely at the interval and price specified for the -subscription. At each subscription renewal, Google Play charges the user account -automatically, then notifies the user of the charges afterward by email. Billing -cycles will always match subscription cycles, based on the purchase date.
- -Over the life of a subscription, the form of payment billed remains the same -— Google Play always bills the same form of payment (such as credit card, -Direct Carrier Billing) that was originally used to purchase the -subscription.
- -When the subscription payment is approved by Google Checkout, Google Play -provides a purchase token back to the purchasing app through the In-app Billing -API. For details, see Purchase token, below. Your apps can -store the token locally or pass it to your backend servers, which can then use -it to validate or cancel the subscription remotely using the Google Play Android Developer API.
- -If a recurring payment fails, such as could happen if the customer’s credit -card has become invalid, the subscription does not renew. Google Play notifies your -app at the end of the active cycle that the purchase state of the subscription is now "Expired". -Your app does not need to grant the user further access to the subscription content.
- -As a best practice, we recommend that your app includes business logic to -notify your backend servers of subscription purchases, tokens, and any billing -errors that may occur. Your backend servers can use the server-side API to query -and update your records and follow up with customers directly, if needed.
- -For any subscription, you can set up a free trial period that lets users -try your subscription content before buying it. The trial period -runs for the period of time that you set and then automatically converts to a full subscription -managed according to the subscription's billing interval and price.
- -To take advantage of a free trial, a user must "purchase" the full -subscription through the standard In-app Billing flow, providing a valid form of -payment to use for billing and completing the normal purchase transaction. -However, the user is not charged any money, since the initial period corresponds -to the free trial. Instead, Google Play records a transaction of $0.00 and the -subscription is marked as purchased for the duration of the trial period or -until cancellation. When the transaction is complete, Google Play notifies users -by email that they have purchased a subscription that includes a free trial -period and that the initial charge was $0.00.
- -When the trial period ends, Google Play automatically initiates billing -against the credit card that the user provided during the initial purchase, at the amount set -for the full subscription, and continuing at the subscription interval. If -necessary, the user can cancel the subscription at any time during the trial -period. In this case, Google Play marks the subscription as expired immediately, -rather than waiting until the end of the trial period. The user has not -paid for the trial period and so is not entitled to continued access after -cancellation.
- -You can set up a trial period for a subscription in the Developer Console, -without needing to modify or update your APK. Just locate and edit the -subscription in your product list, set a valid number of days for the trial -(must be 7 days or longer), and publish. You can change the period any time, -although note that Google Play does not apply the change to users who have -already "purchased" a trial period for the subscription. Only new subscription -purchases will use the updated trial period. You can create one free trial -period per subscription product.
- -Users can view the status of all of their subscriptions and cancel them if -necessary from the My Apps screen in the Play Store app. Currently, the In-app -Billing API does not provide support for canceling subscriptions direct from -inside the purchasing app, although your app can broadcast an Intent to launch -the Play Store app directly to the My Apps screen.
- -When the user cancels a subscription, Google Play does not offer a refund for -the current billing cycle. Instead, it allows the user to have access to the -cancelled subscription until the end of the current billing cycle, at which time -it terminates the subscription. For example, if a user purchases a monthly -subscription and cancels it on the 15th day of the cycle, Google Play will -consider the subscription valid until the end of the 30th day (or other day, -depending on the month).
- -In some cases, the user may contact you directly to request cancellation of a -subscription. In this and similar cases, you can use the server-side API to -query and directly cancel the user’s subscription from your servers. - -
Important: In all cases, you must continue -to offer the content that your subscribers have purchased through their -subscriptions, for as long any users are able to access it. That is, you must -not remove any subscriber’s content while any user still has an active -subscription to it, even if that subscription will terminate at the end of the -current billing cycle. Removing content that a subscriber is entitled to access -will result in penalties. Please see the policies document for more information.
- -When the user uninstalls an app that includes purchased subscriptions, the Play Store app will notify the user that there are active subscriptions. If the user chooses to continue with the uninstalltion, the app is removed and the subscriptions remain active and recurring billing continues. The user can return to cancel the associated subscriptions at any time in the My Apps screen of the Play Store app. If the user chooses to cancel the uninstallation, the app and subscriptions remain as they were.
- -As with other in-app products, Google Play does not provide a refund window -for subscription purchases. For example, users who purchase an app can ask for a -refund from Google Play within a 15-minute window. With subscriptions, Google -Play does not provide a refund window, so users will need to contact you -directly to request a refund. - -
If you receive requests for refunds, you can use the server-side API to -cancel the subscription or verify that it is already cancelled. However, keep in -mind that Google Play considers cancelled subscriptions valid until the end of -their current billing cycles, so even if you grant a refund and cancel the -subscription, the user will still have access to the content. - -
Note: Partial refunds for canceled -subscriptions are not available at this time.
- -In general, the terms of Google Play allow you to sell in-app subscriptions -only through the standard payment processor, Google Checkout. For purchases of any -subscription products, just as for other in-app products and apps, the -transaction fee for subscriptions, just as for other in-app purchases, is the -same as the transaction fee for application purchases (30%).
- -Apps published on Google Play that are selling subscriptions must use In-app -Billing to handle the transaction and may not provide links to a purchase flow -outside of the app and Google Play (such as to a web site).
- -For complete details about terms and policies, see the policies -document.
- -To help you track transactions relating to a given subscription, Google -Checkout provides a base Merchant Order Number for all recurrences of the subscription and denotes -each recurring transaction by appending an integer as follows:
- -12999556515565155651.5565135565155651 (base order number)
-12999556515565155651.5565135565155651..0 (initial purchase orderID)
-12999556515565155651.5565135565155651..1 (first recurrence orderID)
-12999556515565155651.5565135565155651..2 (second recurrence orderID)
-...
Google Play provides that order number to as the value of the
-orderId field of the PURCHASE_STATE_CHANGED
-intent.
In-app purchases of subscriptions are supported only on devices that meet -these minimum requirements:
- -Google Play 3.5 and later versions include support for the In-app Billing -v2 API or higher, which is needed to support handling of subscription -products.
- -As noted in the previous section, support for subscriptions is available only -on devices that meet the system requirements. Not all devices will receive or -install Google Play 3.5, so not all users who install your apps will have access -to the In-app Billing API and subscriptions.
- -If you are targeting older devices that run Android 2.1 or earlier, we -recommend that you offer those users an alternative way buy the content that is -available through subscriptions. For example, you could create standard in-app -products (one-time purchases) that give access to similar content as your -subscriptions, possibly for a longer interval such as a year.
- - -Subscriptions are a standard In-app Billing product type. If you have already -implemented In-app Billing for one-time purchase products, you will find that -adding support for subscriptions is straightforward, with minimal impact on your -code. If you are new to In-app Billing, you can implement subscriptions using -the standard communication model, data structures, and user interactions as for -other in-app products.subscriptions.
- -The full implementation details for In-app Billing are provided outside of -this document, starting with the In-app Billing -Overview. This document is focused on highlighting implementation details -that are specific to subscriptions, along with some strategies for the -associated billing and business models.
- - -To help you get started with your In-app Billing implementation and subscriptions, an updated Version of the In-app Billing sample app is available. @@ -412,7 +34,7 @@ Android SDK Manager. For details, see Downloading the Sample Application.
-With subscriptions, your app uses the standard In-app Billing application model, sending billing requests to the Play Store application over interprocess @@ -436,7 +58,7 @@ app will use the standard set of in-app billing requests and receive the same responses. Inside the requests and responses are two new fields described below.
-Central to the end-to-end architecture for subscriptions is the purchase token, a string value that uniquely identifies (and associates) a user ID and a @@ -476,7 +98,7 @@ href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design document for best practices for maintaining the security of your data.
-Subscriptions support is available only in versions of Google Play that support the In-app Billing v2 API (Google Play 3.5 and higher). For your app, @@ -555,7 +177,7 @@ indicates that subscriptions are supported.
} -Once you’ve checked the API Version as described above and determined that subscriptions are supported, you can present subscription products to the user @@ -630,7 +252,7 @@ BillingService.java).
} -Subscriptions always use the managed by user account purchase type, so that you can restore a record of subscription transactions on the device when @@ -660,7 +282,7 @@ href="{@docRoot}google/play/billing/billing_best_practices.html">Security and Design document for best practices for maintaining the security of your data.
-Subscriptions are time-bound purchases that require successful billing recurrences over time to remain valid. Your app should check the validity of @@ -736,7 +358,7 @@ values for subscription purchases, as received with a -
In-app Billing does not currently provide an API to let users directly view or cancel subscriptions from within the purchasing app. Instead, users can launch the Play @@ -761,7 +383,7 @@ startActivity(intent);
For more information, see Linking to Your Products.
-Google Play notifies your app when the user completes the purchase of a subscription, but the purchase state does not change over time, provided that @@ -786,7 +408,7 @@ purchase state has changed to "Expired".
a change to the same "Expired" purchase state. Once the purchase state has become "Expired", your app does not need to grant further access to the subscription content. -For subscriptions, you make the same types of modifications to your app as
are described in
- To create and manage subscriptions, you use the tools in the Developer
-Console, just as for other in-app products. At the Developer Console, you can configure these attributes for each
-subscription product: For details, please see Administering
-In-app Billing. Google Play offers an HTTP-based API that you can use to remotely query the
-validity of a specific subscription at any time or cancel a subscription. The
-API is designed to be used from your backend servers as a way of securely
-managing subscriptions, as well as extending and integrating subscriptions with
-other services. To use the API, you must first register a project at the Google APIs Console and receive
-a Client ID and shared secret that your app will present when calling the
-Google Play Android Developer API. All calls to the API are authenticated with
-OAuth 2.0. Once your app is registered, you can access the API directly, using standard
-HTTP methods to retrieve and manipulate resources, or you can use the Google
-APIs Client Libraries, which are extended to support the API. The Google Play Android Developer API is built on a RESTful design that uses
-HTTP and JSON, so any standard web stack can send requests and parse the
-responses. However, if you don’t want to send HTTP requests and parse responses
-manually, you can access the API using the client libraries, which provide
-better language integration, improved security, and support for making calls
-that require user authorization. For more information about the API and how to access it through the Google
-APIs Client Libraries, see the documentation at: https://developers.
-google.com/android-publisher/v1/ Applications using the Google Play Android Developer API are limited to an
-initial courtesy usage quota of 15000 requests per day (per
-application). This should provide enough access for normal
-subscription-validation needs, assuming that you follow the recommendation in
-this section. If you need to request a higher limit for your application, please use the
-“Request more” link in the Google APIs Console.
-Also, please read the section below on design best practices for minimizing your
-use of the API. Calls to the Google Play Android Developer API require authorization. Google
-uses the OAuth 2.0 protocol to allow authorized applications to access user
-data. To learn more, see Authorization
-in the Google Play Android Developer API documentation. Access to the Google Play Android Developer API is regulated to help ensure a
-high-performance environment for all applications that use it. While you can
-request a higher daily quota for your application, we highly recommend that you
-minimize your access using the technique(s) below. By following those general guidelines, your implementation will offer the
-best possible performance for users and minimize use of the Google Play Android
-Developer API. December 2012 February 2013 lIZS4
zvqU_$QZ^Uw`QAKthu=j?T2R+}@w}hQt?qSOV`O}GrE?Xp6f*I2U;muQOULCxgtE6^
zC(fGUhDg*LyX&?=H~qE_RG4Ba4aTmA-)@rbuFQK{a4G#x5$L5hHaBK4gv+V8b$?U!
zQ5WtS_N#rGRhH%YrXPb{BR2zF*+OonggCS+LfLF2IMRV9q1X69iBES=r6fY6)9%EL
z)I0BMTBon&tJm;9J#$gs{Ty~9*vgUkLBh(-ZZ+Xu{JYeI)SR4^a#!XmxmNePm9xil
z+PW9tZ-ee#;ReI|Lk~m-{EsK;wJl;8A|O v$HNm3<#>lO)%uEHa
zUwAAmjEon5*W R>#mc5;b?)?W(L@@sNE3qm8{t`|3dR<}pf>p;aLo5Gh&
z4{xP!BuF9QO;_N8wCQPUE8|rJwX{rMt0(vNZbi{>_a!(v8{m|2Vf(}^WRxn@EbhAr
zWowI(MfIua>4B2O=I;VK3e2#C49-d? {g
zg8-25TYntqE_r4=^E@^O5CuUA*n%-ngh3P50O08kFmeb2Vxal`P~pQiZed~J+7OTc
zAYWJf?{1#u#;rF2T7*ma%%?w^6bK^H1vM=Oto8-*!b~5|psnk-J%mJYdtZw+7~uW+
zgPFGc@yVC+kDAk%*blyTqy& 4VO{v$FjYt*Isv&>&SdoAeA~7LsVHjb@qP&%FCUVI&Hk>3
z@-jU&L|wUQ6gP~xliZZkcXM1?8Dt?dT6F)NMVm8&*O~9?p>;I$y2}rIBUg=Ds*v##
zTh~W><3&nubCl@JjQVypmd=M(bxq3H0Y~h 43t!VzG83@*yf{0`R1PaD6LK5`~w0G&{9vCjIQ_dkd=-<8wAdministering Subscriptions
-
-
-
-
-Google Play Android Developer API
-Using the API
-
-Quota
-
-Authorization
-
-Using the API efficiently
-
-
-
-
-
-
- In-app Billing version 3
-
-
In-app Billing version 2
diff --git a/docs/html/images/in-app-billing/v3/billing_subscription_v3.png b/docs/html/images/in-app-billing/v3/billing_subscription_v3.png
new file mode 100644
index 0000000000000000000000000000000000000000..0ba472e91d068fe494d69b8176da7b730d89ab7b
GIT binary patch
literal 27860
zcmYg%WmuF^*Yyno4y8j#iNL_n-Kj`QcT1O)Al)I|9n#V*QqmyZ(jZbIB~p?~zsKkM
zp7(nBL0s1`bMABYUVE>#_K8qYdVz~Yh6Obm>McAkw3_NF@+^Utb(CqrcC&3Psj3}~+304@J_EPHk1=ezR`ppj=wvz;y11RhN*
zuKSk@O88_yc$dZfbFyL*jrLMi4QAEVdJwAH$Ht+esWoNg9X?T|$_vM3gCi9c1fHJP
zkLUbfnleOYi2D1@s3cXe*brJTmR~*DX`Rs*Esv|HFj}VN)u$-w)H3xt{fTgp^bOi#
zRJz+&YAO3kMq8|x7m*oo=QVTr2bU{)UpH9g&%yF*zL&187)H!fy?^Ffe8Y=(vW49Z
zg>5uiw^m-a?zm)q_$AE6|3)#(-hGkml~~pfaf1J%O(eGBfBqEc3;BOV^bsKp&7LSP
z0m
~8BC42u`}$u;lKpFcUvN_Wrbw%XN@Gumj}QCGX6
zsmbzjzYd~jWLF$HY-$*S>woW~70yiy-5D}J&BvZ(w9{0Zj-}L)FvS*ZEut`a>5&9=
z)Q2-#b}b!qTFo