From 57bb89f0b267140ae7f50e31ec0e3023e8836639 Mon Sep 17 00:00:00 2001
From: Dirk Dougherty See also
@@ -68,7 +68,7 @@ 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.
@@ -157,8 +157,9 @@ subscription.When the subscription payment is approved by Google Wallet, 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.
+which can then use it to validate or cancel the subscription remotely using the +Purchase Status 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 @@ -322,93 +323,10 @@ or the {@code PURCHASE_STATE_CHANGED} intent (in V2).
Google Play offers an HTTP-based API that you can use to remotely query the +
Google Play offers an HTTP-based API that lets you 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.
- - +For complete information, see Purchase Status API.
\ No newline at end of file diff --git a/docs/html/google/play/billing/gp-purchase-status-api.jd b/docs/html/google/play/billing/gp-purchase-status-api.jd new file mode 100644 index 0000000..d6b251e --- /dev/null +++ b/docs/html/google/play/billing/gp-purchase-status-api.jd @@ -0,0 +1,166 @@ +page.title=Purchase Status API +page.tags="In-app Billing", "Google Play", "inapp billing", "in app billing", "iab", "billing" + +@jd:body + +Google Play provides an HTTP-based Purchase Status API that lets +you remotely query the status of a specific in-app product or subscription, +or cancel an active subscription. The API is designed to be used from your +backend servers as a way of securely managing in-app products and +subscriptions, as well as extending and integrating them with other services.
+ +With the Purchase Status API you can quickly retrieve the details of any +purchase using a standard GET request. In the request you supply information +about the purchase — app package name, purchase or subscription ID, +and the purchase token. The server responds with a JSON object describing +the associated purchase details, order status, developer payload, and other +information.
+ +You can use the Purchase Status API in several ways, such as for reporting +and reconciliation of individual orders and for verifying purchases and +subscription expirations. You can also use the API to learn about cancelled +orders and confirm whether in-app products have been consumed, including +whether they were consumed before being cancelled.
+ +For subscriptions, in addition to querying for order status and expiration, +you can use the Purchase Status API to remotely cancel a subscription. This is a +convenient way to manage cancellations on behalf of customers, without +requiring them to manage the cancellation themselves on their Android devices.
+ +If you plan to use the Purchase Status API, keep in mind that:
+The Purchase Status API is part of the Google Play Android +Developer API v1.1, available through the Google APIs console. The new version +of the API supersedes the v1 API, which is deprecated. If you are using the v1 +API, please migrate your operations to the v1.1 API as soon as possible.
+ + +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 +API. All calls 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. The 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 Google APIs 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_1/
+ +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.
+ +In a typical scenario, your app verifies the order status for new purchases +to ensure that they are valid before granting access to the purchased content.
+ +To verify a purchase, the app passes the purchase token and other details up +to your backend servers, which verifies them directly with Google Play using the +Purchase Status API. For security reasons, the app should not normally attempt to verify +the purchase itself using the Purchase Status API.
+ +If the backend server determines that the purchase is valid, it notifies the +app and grant access to the content. For improved performance, the backend servers +should store the purchase details and order status in a local database, updated a +intervals or as-needed.
+ +Keep in mind that users will want to be able to use your app at any time, including +when there may be no network connection available. Make sure that your approach to +purchase verification takes account of the offline use-case.
+ +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 techniques 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 1969154..481a79c 100755 --- a/docs/html/google/play/billing/index.jd +++ b/docs/html/google/play/billing/index.jd @@ -10,6 +10,7 @@ and features, and more. You can use In-app Billing to sell products asPURCHASE_STATE_CHANGED
intent.
implemention. -->
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. See Google Play Android Developer API for more information.
+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. See Purchase Status API for more information.
-- cgit v1.1