Home | History | Annotate | Download | only in billing
      1 page.title=In-app Subscriptions
      2 parent.title=In-app Billing
      3 parent.link=index.html
      4 page.metaDescription=Create a steady revenue stream by selling subscriptions to your content.
      5 page.image=/images/play_dev.jpg
      6 page.tags="subscriptions, billing, inapp, iap"
      7 meta.tags="monetization, inappbilling, subscriptions"
      8 @jd:body
      9 
     10 <div id="qv-wrapper">
     11 <div id="qv">
     12   <h2>Quickview</h2>
     13   <h2>In this document</h2>
     14   <ol>
     15     <li><a href="#overview">Overview</a></li>
     16     <li><a href="#administering">Configuring Subscriptions Items</a></li>
     17     <li><a href="#cancellation">Subscription Cancellation</a></li>
     18     <li><a href="#payment">Payment Processing and Policies</a></li>
     19     <li><a href="#strategies">Purchase Verification Strategies</a></li>
     20     <li><a href="#play-dev-api">Google Play Developer API</a></li>
     21   </ol>
     22   <h2>See also</h2>
     23   <ol>
     24     <li><a href="{@docRoot}google/play/billing/billing_integrate.html#Subs">Implementing
     25     Subscriptions (V3)</a></li>
     26     <li><a href="https://developers.google.com/android-publisher/">Google Play
     27     Developer API</a></li>
     28   </ol>
     29 </div>
     30 </div>
     31 
     32 <p>Subscriptions let you sell content, services, or features in your app with
     33 automated, recurring billing. You can easily adapt an existing In-app Billing
     34 implementation to sell subscriptions.</p>
     35 <p>This document is focused on highlighting implementation details that are
     36 specific to subscriptions, along with some strategies for the associated billing
     37 and business models.</p>
     38 
     39   <ul>
     40     <li>Subscriptions let you sell products with automated, recurring billing
     41         at a variety of intervals.</li>
     42     <li>You can offer a configurable trial period for monthly and
     43         annual subscriptions.</li>
     44     <li>You can manage subscriptions through the Developer Console, or by using
     45         the
     46         <a href="https://developers.google.com/android-publisher/">Google Play
     47         Developer API</a>.</li>
     48     <li>Users purchase your subscriptions from inside your apps, rather than
     49         directly from Google Play.</li>
     50     <li>Users can renew their subscriptions while a current subscription is
     51         active.</li>
     52     <li>Users can upgrade or downgrade a subscription in the middle of a
     53         subscription period. The old subscription's cost is pro-rated, and the
     54         unused portion is applied to the replacement subscription.</li>
     55     <li>You can defer billing for a particular user's subscription, to manage
     56         accounts or offer rewards.</li>
     57   </ul>
     58 
     59 <h2 id="overview">Overview</h2>
     60 <p>A <em>subscription</em> is a product type offered in In-app Billing that
     61 lets you sell content, services, or features to users from inside your app with
     62 recurring, automated billing at the interval you specify. You can sell subscriptions to almost
     63 any
     64 type of digital content, from any type of app or game.</p>
     65 
     66 <p>As with other in-app products, you configure and publish subscriptions using
     67 the Developer Console and then sell them from inside apps installed on
     68 Android devices. In the Developer console, you create subscription
     69 products and add them to a product list, then set a price and optional trial
     70 period for each, choose a billing interval, and then
     71 publish. For more information about using the Developer Console, see
     72 <a href="#administering">Configuring Subscription Items</a>.</p>
     73 
     74 <p>When users purchase subscriptions in your apps, Google Play handles all
     75 checkout details so your apps never have to directly process any financial
     76 transactions. Google Play processes all payments for subscriptions through
     77 Google payments, just as it does for standard in-app products and app purchases.
     78 This ensures a consistent and familiar purchase flow for your users.</p>
     79 
     80 <img src="{@docRoot}images/in-app-billing/v3/billing_subscription_v3.png" style="float:right; border:4px solid ddd;">
     81 
     82 <p>After users have purchased subscriptions, they can view the subscriptions and
     83 cancel them from the <strong>My Apps</strong> screen in the Play Store app or
     84 from the app's product details page in the Play Store app. For more information
     85 about handling user cancellations, see <a href="#cancellation">Subscription Cancellation</a>.</p>
     86 
     87 <p>In addition to client-side API calls, you can use the server-side API for
     88 In-app Billing to provide subscription purchasers with extended access to
     89 content (for example, from your web site or another service).
     90 The server-side API lets you validate the status of a subscription when users
     91 sign into your other services. For more information about the API, see <a
     92 href="{@docRoot}google/play/developer-api.html">Google Play Developer API</a>. </p>
     93 
     94 <p>You can also build on your existing external subscriber base from inside your
     95 Android apps.</p>
     96 <ul>
     97 <li>If you sell subscriptions on a web site, for example, you can add
     98 your own business logic to your Android app to determine whether the user has
     99 already purchased a subscription elsewhere, then allow access to your content if
    100 so or offer a subscription purchase from Google Play if not.</li>
    101 <li>You can implement your own solution for sharing subscriptions across as
    102 many different apps or products as you want. For example, you could sell a
    103 subscription that gives a subscriber access to an entire collection of apps,
    104 games, or other content for a monthly or annual fee. To implement this solution,
    105 you could add your own business logic to your app to determine whether the user
    106 has already purchased a given subscription and if so, allow access to your
    107 content.</li>
    108 </ul>
    109 </p>
    110 
    111 <p>In general the same basic policies and terms apply to subscriptions as to
    112 standard in-app products, however there are some differences. For complete
    113 information about the current policies and terms, please read the <a
    114 href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=140504">
    115 policies document</a>.</p>
    116 
    117 <p>To learn about the minimum system requirements for
    118 subscriptions, see the <a href="{@docRoot}google/play/billing/versions.html#Subs">
    119 Version Notes</a>.</p>
    120 
    121 <h2 id="administering">Configuring Subscription Items</h2>
    122 
    123 <p>To create and manage subscriptions, you can use the Developer Console to set
    124 up a
    125 product list for the app, then configure these attributes for each subscription
    126 product:</p>
    127 
    128 <ul>
    129 <li>Purchase Type: always set to <strong>Subscription</strong></li>
    130 <li>Subscription ID:  An identifier for the subscription</li>
    131 <li>Publishing State: Unpublished/Published</li>
    132 <li>Language: The default language for displaying the subscription</li>
    133 <li>Title: The title of the subscription product</li>
    134 <li>Description: Details that tell the user about the subscription</li>
    135 <li>Price: Default price of subscription per recurrence</li>
    136 <li>Recurrence: Interval of billing recurrence</li>
    137 <li>Additional currency pricing (can be auto-filled)</li>
    138 </ul>
    139 
    140 <p>For details on how to add and configure products in the Developer Console,
    141 see <a href="{@docRoot}google/play/billing/billing_admin.html">Administering
    142 In-app Billing</a>.</p>
    143 
    144 <p>You can also create and manage subscriptions using the
    145 <a href="{@docRoot}google/play/developer-api.html">
    146 Google Play Developer API</a>.</p>
    147 
    148 <h3 id="pricing">Subscription pricing</h3>
    149 
    150 <p>When you create a subscription in the Developer Console, you can set a price
    151 for it in any available currencies. Each subscription must have a non-zero
    152 price. You can price multiple subscriptions for the same content differently
    153 &mdash; for example you could offer a discount on an annual subscription
    154 relative to the monthly equivalent. </p>
    155 
    156 <p class="caution"><strong>Important</strong>: To change the price of a
    157 subscription, you can publish a new subscription product ID at a new price,
    158 then offer it in your app instead of the original product. Users who have
    159 already purchased will continue to be charged at the
    160 original price, but new users will be charged at the new price.</p>
    161 
    162 <h3 id="user-billing">User billing</h3>
    163 
    164 <p>In the Developer Console, you can configure subscription products with
    165 automated recurring billing at your choice of intervals:</p>
    166 
    167 <ul>
    168   <li>Weekly &mdash; Google Play bills the customers Google payments account at
    169   the time of purchase and every week after the original purchase date.</li>
    170   <li>Monthly &mdash; Google Play bills the customers Google payments account at
    171   the time of purchase and monthly subsequent to the purchase date (exact billing
    172   intervals can vary slightly over time).</li>
    173   <li>3 Months &mdash; Google Play bills the customers Google payments account at
    174   the time of purchase and every three months after that (exact billing
    175   intervals can vary slightly over time).</li>
    176   <li>6 Months &mdash; Google Play bills the customers Google payments account at
    177   the time of purchase and every six months after that (exact billing
    178   intervals can vary slightly over time).</li>
    179   <li>Annually &mdash; Google Play bills the customer's Google payments account at
    180   the time of purchase and again on the same date in subsequent years.</li>
    181   <li>Seasonal &mdash; Google Play bills the customer's Google payments account at
    182   the beginning of each "season" (you specify the season beginning and end
    183   dates). This
    184   is intended for annual purchases of seasonal content (such as sports-related
    185   content). The subscription runs through the end of the season, and restarts
    186   the next year at the start of the season.</li>
    187 
    188 </ul>
    189 
    190 <p>Billing continues indefinitely at the interval and price specified for the
    191 subscription. At each subscription renewal, Google Play charges the user account
    192 automatically, then notifies the user of the charges afterward by email. For
    193 monthly and annual subscriptions, billing cycles will always match subscription
    194 cycles, based on the purchase date. (Seasonal subscriptions are charged
    195 annually, on the first day of the season.)</p>
    196 
    197 <p>When the subscription payment is approved, Google Play
    198 provides a purchase token back to the purchasing app through the In-app Billing
    199 API. Your apps can store the token locally or pass it to your backend servers,
    200 which can then use it to validate or cancel the subscription remotely using the
    201 <a
    202 href="{@docRoot}google/play/developer-api.html">Google Play Developer API</a>.</p>
    203 
    204 <p>If a recurring payment fails (for example, because the customers credit
    205 card has become invalid), the subscription does not renew. The {@code
    206 getPurchases()} method does not return failed or expired subscriptions.</p>
    207 
    208 <p class="note"><strong>Recommendation</strong>: Include business logic in your
    209 app to notify your backend servers of subscription purchases, tokens, and any
    210 billing errors that may occur. Your backend servers can use the server-side API
    211 to query and update your records and follow up with customers directly, if needed.</p>
    212 
    213 <h3 id="manual-renewal">Manual Renewal</h3>
    214 
    215 <p>With version 3 of the In-app Billing API, users can renew a subscription
    216 during its active period even if the subscription is not set to
    217 automatically renew. If the user purchases a subscription while the subscription
    218 is active, it is extended by the appropriate period at the current rate.</p>
    219 
    220 <p>For example, Achilles has a subscription to the <em>Modern Hoplite</em> app.
    221 His subscription is currently due to expire on August 1. On July 10, he
    222 purchases a 1-month subscription at the current rate. This one month is
    223 added to his existing subscription, so the subscription now expires on September
    224 1.</p>
    225 
    226 <p>It is up to the app to convey this with an appropriate UI. For example, if a
    227 user does not have an active subscription, the app might have a
    228 <strong>buy</strong> button, but if the user has a subscription the button might
    229 say <strong>renew</strong>.</p>
    230 
    231 <h3 id="upgrade">Subscription Upgrade/Downgrade</h3>
    232 
    233 <p>
    234   With version 3 of the In-app Billing API, users can upgrade or downgrade a
    235   subscription during its active period. When the user does this, the active
    236   subscription is canceled and a new subscription is created. The unused
    237   balance of the old subscription is applied on a pro-rated basis to the new
    238   subscription. The first billing period for the new subscription begins after
    239   that balance is used up. (The new subscription does not need to have a period
    240   of the same length as the old one.)
    241 </p>
    242 
    243 <p>For example, Samwise has a subscription to online content from the
    244 <em>Country Gardener</em> app. He currently has a monthly subscription to the
    245 Tier 1
    246 version of the content (which has text-only content). This subscription costs
    247 him 2/month, and renews on the first of the month. On April
    248 15, he chooses to upgrade to the Tier 2 subscription (which includes video
    249 updates), costing 3/month. His Tier 1 subscription is immediately ended.
    250 Since he paid for a full month (April 1-30), but only used half of it, half of a
    251 month's subscription (1) is applied to his new subscription. However, since
    252 that new subscription costs 3/month, the 1 credit balance only pays for ten
    253 days. So Samwise's credit pays for his subscription from April 15-25. On April
    254 26, he is charged 3 for his new subscription, and another 3 on the 26th of
    255 each month following.</p>
    256 
    257 <p class="note">
    258   <strong>Note:</strong> The new subscription's billing date depends on when
    259   the subscriber's pro-rated credit runs out, so the subscriber cannot upgrade
    260   or downgrade to a seasonal subscription, which has fixed and predetermined
    261   beginning and end dates.
    262 </p>
    263 
    264 <p>When a user upgrades or downgrades a subscription, your app calls
    265 <a href="{@docRoot}google/play/billing/billing_reference.html#upgrade-getBuyIntentToReplaceSkus">
    266 <code>getBuyIntentToReplaceSkus()</code></a>.
    267 This method is passed the new SKU the user wants to buy, and all
    268 the old SKUs that are superseded by it. The remaining portions of the old SKUs
    269 are used to pay for the new subscription, and billing begins when this credit
    270 is used up.</p>
    271 
    272 <h3 id="deferred-billing">Deferred Billing</h3>
    273 
    274 <p>Using the
    275 <a href="{@docRoot}google/play/developer-api.html">Google
    276 Play Developer API</a>, you can defer the next billing date for a
    277 subscriber. The user continues to be subscribed to the content, and has full
    278 access to it, but is not charged during the deferral period. This allows you
    279 to do things like:</p>
    280 
    281 <ul>
    282   <li>Give users free access as part of a bundle or a special offer (for
    283     example, giving free access to web content to users who subscribe to a
    284     print magazine)</li>
    285   <li>Give free access to customers as a goodwill gesture</li>
    286 </ul>
    287 
    288 <p>The longest you can defer billing is for one year per call. Of course, you
    289 can call the API again before the year is up to defer billing further.</p>
    290 
    291 <p>For example, Darcy has a monthly subscription to online content for the
    292 <em>Fishing Gentleman</em> app. He is normally
    293 billed 1.25 on the first of each month.
    294 On March 10, he participates in an online survey for the app publisher. The
    295 publisher rewards him by deferring his next payment until June 1. Darcy is not
    296 charged on April 1 or May 1, but still has access to the content as normal. On
    297 June 1, he is charged his normal 1.25 subscription fee.</p>
    298 
    299 <p class="note"><strong>Note:</strong> The API always defers the billing date
    300 by a whole number of days. If you request a deferral period that includes a
    301 fractional number of days, the API rounds the period up to the next full day.
    302 For example, if a user's subscription is set to renew on 15 June 2015 at
    303 14:00:00 UTC, and you use the API to defer the renewal date to 15 August 2015 at
    304 02:00:00 UTC, the API will round up to the next full day and set the renewal
    305 date to 15 August 2015 14:00:00 UTC.</p>
    306 
    307 <p>You can also offer free trials to new subscribers, as described in
    308 <a href="#trials">Free trials</a>.</p>
    309 
    310 <h3 id="trials">Free trials</h3>
    311 
    312 <p>In the Developer Console, you can set up a free trial period that lets users
    313 try your subscription content before buying it. The trial period runs for the
    314 period of time that you set and then automatically converts to a full
    315 subscription managed according to the subscription's billing interval and
    316 price. Google Play supports free trials for all subscription types, including
    317 seasonal subscriptions.</p>
    318 
    319 <p>To take advantage of a free trial, a user must "purchase" the full
    320 subscription through the standard In-app Billing flow, providing a valid form of
    321 payment to use for billing and completing the normal purchase transaction.
    322 However, the user is not charged any money, because the initial period
    323 corresponds
    324 to the free trial. Instead, Google Play records a transaction of $0.00 and the
    325 subscription is marked as purchased for the duration of the trial period or
    326 until cancellation. When the transaction is complete, Google Play notifies users
    327 by email that they have purchased a subscription that includes a free trial
    328 period and that the initial charge was $0.00. </p>
    329 
    330 <p>When the trial period ends, Google Play automatically initiates billing
    331 against the credit card that the user provided during the initial purchase, at
    332 the amount set
    333 for the full subscription, and continuing at the subscription interval. If
    334 necessary, the user can cancel the subscription at any time during the trial
    335 period. In this case, the subscription remains active until the end of the
    336 trial period, but Google Play sets the subscription <em>not</em> to renew
    337 automatically; at the end of the trial period the subscription expires, and
    338 Google Play does not charge the user.</p>
    339 
    340 <p>You can set up a trial period for a subscription in the Developer Console,
    341 without needing to modify or update your APK. Just locate and edit the
    342 subscription in your product list, set a valid number of days for the trial
    343 (must be 7 days or longer), and publish. You can change the period any time,
    344 although note that Google Play does not apply the change to users who have
    345 already "purchased" a trial period for the subscription. Only new subscription
    346 purchases will use the updated trial period. You can create one free trial
    347 period per subscription product.</p>
    348 
    349 <h3 id="publishing">Subscription publishing</h3>
    350 
    351 <p>When you have finished configuring your subscription product details in the
    352 Developer Console or via the API,
    353 you can publish the subscription in the app product list.</p>
    354 
    355 <p>In the product list, you can add subscriptions, in-app products, or both. You
    356 can add multiple subscriptions that give access to different content or
    357 services, or you can add multiple subscriptions that give access to the same
    358 content but for different intervals or different prices, such as for a
    359 promotion. For example, a news outlet might decide to offer both monthly and
    360 annual subscriptions to the same content, with annual having a discount. You can
    361 also offer in-app purchase equivalents for subscription products, to ensure that
    362 your content is available to users of older devices that do not support
    363 subscriptions.</p>
    364 
    365 <p>After you add a subscription or in-app product to the product list, you must
    366 publish the product before Google Play can make it available for purchase. Note
    367 that you must also publish the app itself before Google Play will make the
    368 products available for purchase inside the app. </p>
    369 
    370 <p class="caution"><strong>Important</strong>: You can remove the subscription
    371 product from the product list offered in your app to prevent users from seeing
    372 or purchasing it.</p>
    373 
    374 <h3 id="prorate">Prorated Seasonal Subscription Prices</h3>
    375 
    376 <p>You can set up prorated prices for users who buy seasonal subscriptions
    377 after the season's start date. You specify the date on which the discounted
    378 price takes effect. The discounted price takes effect at 0:00 UTC on
    379 the specified date. You can set multiple prorated prices, dropping the
    380 subscription price lower and lower as the season goes on. If a user purchases
    381 a prorated seasonal subscription and remains subscribed until the start of the
    382 next season, Google Play charges them the full subscription price when the next
    383 season starts.</p>
    384 
    385 <p>For example, the professional checkers season runs from March 1 to August 31.
    386 The <em>Checkers Dilettante</em> app offers a seasonal subscription for 10. The
    387 app also offers two prorated prices: 7.50 for users who sign up on or after
    388 June 1, and 5 for users who sign up on or after
    389 August 15. Regardless of when the user signs up, the seasonal subscription ends
    390 on August 31.</p>
    391 
    392 <h2 id="cancellation">Subscription Cancellation</h2>
    393 
    394 <p>Users can view the status of all of their subscriptions and cancel them if
    395 necessary from the <strong>My Apps</strong> screen in the Play Store app.
    396 Currently, the In-app Billing API does not provide support for programatically
    397 canceling subscriptions from inside the purchasing app.</p>
    398 
    399 <p>When the user cancels a subscription, Google Play does not offer a refund for
    400 the current billing cycle. Instead, it allows the user to have access to the
    401 canceled subscription until the end of the current billing cycle, at which time
    402 it terminates the subscription. For example, if a user purchases a monthly
    403 subscription and cancels it on the 15th day of the cycle, Google Play will
    404 consider the subscription valid until the end of the 30th day (or other day,
    405 depending on the month).</p>
    406 
    407 <p>In some cases, the user may contact you directly to request cancellation of a
    408 subscription. In this and similar cases, you can use the server-side API to
    409 query and directly cancel the users subscription from your servers.
    410 
    411 <p class="caution"><strong>Important:</strong> In all cases, you must continue
    412 to offer the content that your subscribers have purchased through their
    413 subscriptions, as long any user is able to access it. That is, you must
    414 not remove any content while any user still has an active
    415 subscription to it, even if that subscription will terminate at the end of the
    416 current billing cycle. Alternatively, you can use the <a href="#refunds">refund
    417 and revoke</a> API to revoke each subscriber's subscription (one by one) and
    418 refund their subscription payments.
    419 Removing content that any subscriber is entitled to access
    420 will result in penalties. Please see the <a
    421 href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=140504">
    422 policies document</a> for more information. </p>
    423 
    424 <h3 id="uninstall">App uninstallation</h3>
    425 
    426 <p>When the user uninstalls an app that includes purchased subscriptions, the
    427 Play Store app will notify the user that there are active subscriptions. If the
    428 user chooses to continue with the uninstallation, the app is removed and the
    429 subscriptions remain active and recurring billing continues. The user can return
    430 to cancel the associated subscriptions at any time in the <strong>My Apps</strong>
    431 screen of the Play Store app. If the user chooses to cancel the uninstallation,
    432 the app and subscriptions remain as they were.</p>
    433 
    434 <h3 id="refunds">Refunding and revoking subscriptions</h3>
    435 
    436 <p>With subscriptions, Google Play does not provide a refund window, so users
    437 will need to request a refund. They can request a refund from the <strong>My
    438 Orders</strong> page in the Play Store, or by contacting you directly.</p>
    439 
    440 <p>If you receive requests for refunds, you can use the
    441 <a href="{@docRoot}google/play/developer-api.html">Google Play
    442 Developer API</a> or the Merchant Center to cancel the subscription, verify that it
    443 is already canceled, or refund the user's payment without canceling it. You
    444 can also use the
    445 <a href="{@docRoot}google/play/developer-api.html">Google
    446 Play Developer API</a> to <em>refund and revoke</em> a
    447 user's subscription. If you refund and revoke a subscription, the user's
    448 subscription is immediately canceled, and the user's most recent subscription
    449 payment is refunded. (If you want to refund more than the most recent payment,
    450 you can process additional refunds through the Merchant Center.)</p>
    451 
    452 <p class="caution"><strong>Important:</strong> Partial refunds are not available
    453 at this time.</p>
    454 
    455 <h2 id="payment">Payment Processing and Policies</h2>
    456 
    457 <p>In general, the terms of Google Play allow you to sell in-app subscriptions
    458 only through the standard payment processor, Google payments. For purchases of
    459 any subscription products, the transaction fee is the same as the transaction
    460 fee for application purchases (30%).</p>
    461 
    462 <p>Apps published on Google Play that are selling subscriptions must use In-app
    463 Billing to handle the transaction and may not provide links to a purchase flow
    464 outside of the app and Google Play (such as to a web site).</p>
    465 
    466 <p>For complete details about terms and policies, see the <a
    467 href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=140504">
    468 policies document</a>.</p>
    469 
    470 <h3 id="orderId">Subscription order numbers</h3>
    471 
    472 <p>To help you track transactions relating to a given subscription, Google
    473 payments provides a base Merchant Order Number for all recurrences of the
    474 subscription and denotes
    475 each recurring transaction by appending an integer as follows: </p>
    476 
    477 <p><span style="color:#777"><code style="color:#777">GPA.1234-5678-9012-34567</code>
    478 (base order number)</span><br />
    479 <code>GPA.1234-5678-9012-34567..0</code> (first recurrence orderID)<br />
    480 <code>GPA.1234-5678-9012-34567..1</code> (second recurrence orderID)<br />
    481 <code>GPA.1234-5678-9012-34567..2</code> (third recurrence orderID)<br />
    482 ...<br /></p>
    483 
    484 <p>Google Play provides the order number as the value of the
    485 {@code orderId} field of the {@code INAPP_PURCHASE_DATA} JSON field (in V3)
    486 or the {@code PURCHASE_STATE_CHANGED} intent (in V2).</p>
    487 
    488 <h3 id="grace-period">Grace period for declined payments</h3>
    489 
    490 <p>
    491   The Developer Console allows you to set a grace period for subscriptions, so you can give
    492   your subscribers a chance to update their payment method if a recurring payment is declined.
    493   This setting is useful if your subscribers have an expired credit card, subscribed using a
    494   prepaid card, or canceled a card without updating their payment information. For
    495   information about setting a grace period for subscriptions, see the Developer Console Help
    496   topic <a href="https://support.google.com/googleplay/android-developer/answer/140504"
    497   class="external-link">Add subscriptions &amp; recurring charges</a>.
    498 </p>
    499 
    500 </p>
    501   For information on how setting a grace period affects data returned from the
    502   {@code getBuyIntent()} method, see the
    503   <a href="{@docRoot}google/play/billing/billing_reference.html#purchase-data-table"
    504   >{@code INAPP_PURCHASE_DATA}</a> fields table.
    505 </p>
    506 
    507 <h2 id="strategies">Purchase Verification Strategies</h2>
    508 
    509 <p>In a typical scenario, your app verifies the order status for new purchases
    510 to ensure that they are valid before granting access to the purchased
    511 content.</p>
    512 
    513 <p>To verify a purchase, the app passes the purchase token and other details up
    514 to your backend servers, which verifies them directly with Google Play using the
    515 Google Play Developer API.  If the backend server determines that the purchase is
    516 valid, it notifies the app and grants access to the content.</p>
    517 
    518 <p>Keep in mind that users will want the ability to use your app at any time,
    519 including when there may be no network connection available. Make sure that your
    520 approach to purchase verification accounts for the offline use-case.</p>
    521 
    522 <h2 id="play-dev-api">Google Play Developer API</h2>
    523 
    524 <p>Google Play offers an HTTP-based API that lets you perform such tasks as:</p>
    525   <ul>
    526     <li>Remotely query the validity of a specific subscription at any time</li>
    527     <li>Cancel a subscription</li>
    528     <li>Defer a subscription's next billing date</li>
    529     <li>Refund a subscription payment without canceling the subscription</li>
    530     <li>Refund and revoke a subscription</li>
    531   </ul>
    532 
    533 <p>The API is designed to be used from your backend servers as a way of securely
    534 managing subscriptions, as well as extending and integrating subscriptions with
    535 other services.</p>
    536 
    537 <p>For complete information, see
    538 <a href="{@docRoot}google/play/developer-api.html">Google Play
    539 Developer API</a>.</p>
    540