Home | History | Annotate | Download | only in billing
      1 page.title=Testing In-app Billing
      2 parent.title=In-app Billing
      3 parent.link=index.html
      4 page.tags="inapp, billing, iap"
      5 @jd:body
      6 
      7 <div id="qv-wrapper">
      8 <div id="qv">
      9   <h2>In this document</h2>
     10   <ol>
     11     <li><a href="#testing-purchases">Testing In-app Purchases</a></li>
     12     <li><a href="#billing-testing-static">Testing with Static Responses</a></li>
     13     <li><a href="#billing-testing-test">Setting Up for Test Purchases</a></li>
     14     <li><a href="#draft_apps">Draft Apps are No Longer Supported</a></li>
     15   </ol>
     16   <h2>See also</h2>
     17   <ol>
     18     <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
     19     Billing</a></li>
     20   <ol>
     21 </div>
     22 </div>
     23 
     24 <p>The Google Play Developer Console provides several tools that help you test your In-app Billing
     25 implementation:</p>
     26 
     27 <ul>
     28 <li>Test purchases, which let license-test users purchase your published in-app
     29     items, without any actual charges to their accounts.</li>
     30 <li>Static billing responses from Google Play, for testing in early development</p>
     31 </ul>
     32 
     33 <p>To test in-app billing, you need to publish your app to an <a
     34 href="https://support.google.com/googleplay/android-developer/answer/3131213">alpha
     35 or beta channel in Google Play.</a></p>
     36 
     37 <p>After you publish an app to an alpha or beta channel, it can take a few hours
     38 for the app to be available for testers. The version code of an APK on a test device
     39 must match the version currently uploaded to the alpha or beta channel on Google Play.</p>
     40 
     41 <p class="caution"><strong>Important</strong>: To test in-app products or make in-app
     42 purchases in your alpha or beta channel app, each tester
     43 needs to <a href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in
     44 to your apps alpha or beta test</a>. On your tests opt-in URL, your
     45 testers will get an explanation of what it means to be a tester and a link to opt-in.</p>
     46 
     47 <p>You can test on any Android-powered hardware device running Android 1.6 or higher.
     48 The most current version of the Google Play application must be installed on the device.
     49 For general information about how to set up a device for use in
     50 developing Android applications, see <a href="{@docRoot}tools/device.html">Using Hardware
     51 Devices</a>.</p>
     52 
     53 <h2 id="testing-purchases">Testing In-app Purchases</h2>
     54 
     55 <p>When your In-app Billing implementation is ready, you can test purchasing of your in-app SKUs in two ways:</p>
     56 
     57 <ul>
     58 <li><strong>Test purchases</strong>, which let your selected license-test
     59 users purchase your in-app products without any resulting charges to the user.
     60 Test purchases can be used in alpha/beta releases only. </li>
     61 <li><strong>Real purchases</strong>, which let regular users make real purchases
     62 of your in-app products with actual charges to the users payment instruments.</li>
     63 </ul>
     64 
     65 <p>In either case, you need to publish your app to Google Play's
     66 <a href="https://support.google.com/googleplay/android-developer/answer/3131213">alpha
     67   and beta release channels</a> to manage the users who can make purchases.</p>
     68 
     69   <p>The sections below provide more detail about how to use these approaches for
     70 testing and validation. </p>
     71 
     72 
     73 
     74 <h3 id="test-purchases">Test Purchases (In-app Billing Sandbox)</h3>
     75 
     76 <p>Test purchases offer a secure, convenient way to enable larger-scale testing
     77 of your In-app Billing implementation during development or in preparation for
     78 launch. They let authorized user accounts make purchases of your in-app products
     79 through Google Play without incurring any actual charges to the user
     80 accounts.</p>
     81 
     82 <p>
     83   Once authorized for testing access, those users can make purchases without
     84   being charged. Test purchases don't have an <code>orderId</code> field, which
     85   ensures that there are no actual charges to user accounts.
     86 </p>
     87 
     88 <p class="note">
     89   <strong>Note:</strong> Test subscription purchases recur daily, regardless of
     90   the product's subscription period.
     91 </p>
     92 
     93 
     94 <h4 id="setup">Setting up test purchases</h4>
     95 
     96 <p>Its easy to set up test purchases&mdash;any user account can be chosen to be
     97 a test account, and any user of a test account can make test purchases with any
     98 available payment method (even though theres no charge to the payment
     99 method).</p>
    100 
    101 <p>First, upload and publish in-app products that you want testers to be able to
    102 purchase. You can upload and publish in-app products in the Developer Console.
    103 Note that you can upload and publish your in-app items before you publish the
    104 APK itself.</p>
    105 
    106 <p>Next, create license test accounts for authorized users. In the Developer
    107 Console, go to <strong>Settings</strong> &gt; <strong>Account details</strong>,
    108 then in the License Testing section, add the addresses to <strong>Gmail accounts
    109 with testing access</strong> field. For more information, see <a
    110 href="#billing-testing-test">Setting Up for Test Purchases</a>.</p>
    111 
    112 <p>Once youve added the users as license tester accounts and saved the change,
    113 within 15 minutes those users can begin making test purchases of your in-app
    114 products.</p>
    115 
    116 <p class="caution"><strong>Important</strong>: After you publish your app
    117 to an alpha or beta channel, your testers need to <a
    118 href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in
    119 to your apps alpha or beta test</a> using the provided opt-in URL before they
    120 can make test purchases. </p>
    121 
    122 <p class="note"><strong>Note</strong>: License test accounts
    123 must be on the users Android device. If the device has more than one
    124 account, the purchase will be made with the account that downloaded the app. If
    125 none of the accounts has downloaded the app, the purchase is made with the first
    126 account. Users can confirm the account that is making a purchase by expanding the
    127 purchase dialog.</p>
    128 
    129 <p class="note">
    130   <strong>Note:</strong> Test purchases don't have an <code>orderId</code>
    131   field. To track test purchases, you use the <code>purchaseToken</code> field
    132   instead.
    133 </p>
    134 
    135 <h4 id="tp-account">Test purchases and developer account</h4>
    136 <p>Authorized license test accounts are associated with your developer account
    137 in Google Play, rather than with a specific APK or package name. Identifying an
    138 account as a test account enables it to purchase any of your in-app products
    139 without being charged. </p>
    140 
    141 <h4 id="purchase-flow">Details of purchase flow</h4>
    142 <p>During a test purchase, users can test the actual merchandising, purchase,
    143 and fulfillment flow in your app.  During purchase, the inapp item is displayed
    144 as a normal item with an actual price. However, Google Play marks test purchases
    145 with a notice across the center of the purchase dialog, for easy identification.
    146 </p>
    147 
    148 <h4 id="cancelling">Canceling completed test purchases</h4>
    149 <p>Google Play accumulates completed test purchases for each user but does not
    150 pass them on to financial processing.</p>
    151 
    152 <p>In some cases, you might want to manually cancel a test purchase to continue
    153 testing. To do so, open the app page in the Play Store. If the test purchase
    154 that you want to cancel is a subscription, you can also use the
    155 <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/cancel">
    156 {@code cancel()}</a> method of the Purchases.subscriptions API.
    157 </ul>
    158 
    159 <p class="caution">
    160   <strong>Important:</strong> The
    161   <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/refund">
    162   {@code refund()}</a> and
    163   <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/revoke">
    164   {@code revoke()}</a> methods of the Purchases.subscriptions API don't support
    165   test purchases.
    166 </p>
    167 
    168 
    169 <h3 id="transations">Testing with real transactions</h3>
    170 <p>As you prepare to launch an app that uses In-app Billing, you can make use of
    171 Google Play alpha/beta release options to do validation and load testing on your
    172 implementation before distributing the app to all of your users. </p>
    173 
    174 <p>With alpha/beta test groups, real users (chosen by you) can install your app
    175 from Google Play and test your in-app products. They can make real purchases
    176 that result in actual charges to their accounts, using any of their normal
    177 payment methods in Google Play to make purchases. Note that if you include test
    178 license accounts in your alpha and beta distribution groups, those users will
    179 only be able to make test purchases. </p>
    180 
    181 <p class="caution"><strong>Important</strong>: After you publish your app
    182 to an alpha or beta channel, your testers need to <a
    183 href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in
    184 to your apps alpha or beta test</a> using the provided opt-in URL before they
    185 can make test purchases. </p>
    186 
    187 
    188 <h2 id="billing-testing-static">Testing with Static Responses</h2>
    189 
    190 <p>We recommend that you first test your In-app Billing implementation using static responses from
    191 Google Play. This enables you to verify that your application is handling the primary Google
    192 Play responses correctly and that your application is able to verify signatures correctly. You can
    193 do this even if the app hasn't been published yet.</p>
    194 
    195 <p>To test your implementation with static responses, you make an In-app Billing request using a
    196 special item that has a reserved product ID. Each reserved product ID returns a specific static
    197 response from Google Play. No money is transferred when you make In-app Billing requests with the
    198 reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
    199 with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
    200 product ID android.test.purchased.</p>
    201 
    202 <img src="{@docRoot}images/billing_test_flow.png" height="381" id="figure1" />
    203 <p class="img-caption">
    204   <strong>Figure 1.</strong>Purchase flow for the special reserved item android.test.purchased.
    205 </p>
    206 
    207 <p>You do not need to list the reserved products in your application's product list. Google Play
    208 already knows about the reserved product IDs. Also, you do not need to upload your application to
    209 the Developer Console to perform static response tests with the reserved product IDs. You can simply
    210 install your application on a device, log into the device, and make billing requests using the
    211 reserved product IDs.</p>
    212 
    213 <p class="note"><strong>Note:</strong> Previously you could test an app by
    214 uploading an unpublished "draft" version. This functionality is no longer
    215 supported. However, you can test your app with static responses even before you
    216 upload it to the Google Play store. For more information, see <a
    217 href="#draft_apps">Draft Apps are No Longer Supported</a>.
    218 
    219 <p>There are four reserved product IDs for testing static In-app Billing responses:</p>
    220 
    221 <ul>
    222   <li><strong>android.test.purchased</strong>
    223     <p>When you make an In-app Billing request with this product ID, Google Play responds as
    224     though you successfully purchased an item. The response includes a JSON string, which contains
    225     fake purchase information (for example, a fake order ID). In some cases, the JSON string is
    226     signed and the response includes the signature so you can test your signature verification
    227     implementation using these responses.</p>
    228   </li>
    229   <li><strong>android.test.canceled</strong>
    230     <p>When you make an In-app Billing request with this product ID Google Play responds as
    231     though the purchase was canceled. This can occur when an error is encountered in the order
    232     process, such as an invalid credit card, or when you cancel a user's order before it is
    233     charged.</p>
    234   </li>
    235   <li><strong>android.test.refunded</strong>
    236     <p>When you make an In-app Billing request with this product ID, Google Play responds as
    237     though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
    238     billing service. Refunds must be initiated by you (the merchant). After you process a refund
    239     request through your Google payments merchant account, a refund message is sent to your application by
    240     Google Play. This occurs only when Google Play gets notification from Google payments that
    241     a refund has been made. For more information about refunds, see <a
    242     href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
    243     IN_APP_NOTIFY messages</a> and <a
    244     href="http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=1153485"
    245     >In-app Billing Pricing</a>.</p>
    246   </li>
    247   <li><strong>android.test.item_unavailable</strong>
    248     <p>When you make an In-app Billing request with this product ID, Google Play responds as
    249     though the item being purchased was not listed in your application's product list.</p>
    250   </li>
    251 </ul>
    252 
    253 <p>In some cases, the reserved items may return signed static responses, which
    254 lets you test signature verification in your application. The reserved items
    255 only return signed responses if the user running the application has a <a
    256 href="{@docRoot}distribute/googleplay/start.html">developer</a> or <a
    257 href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test
    258 account.</a>
    259 
    260 <p>To make an In-app Billing request with a reserved product ID, you simply construct a normal
    261 <code>REQUEST_PURCHASE</code> request, but instead of using a real product ID from your
    262 application's product list you use one of the reserved product IDs.</p>
    263 
    264 <p>To test your application using the reserved product IDs, follow these steps:</p>
    265 
    266 <ol>
    267   <li><strong>Install your application on an Android-powered device.</strong>
    268     <p>You cannot use the emulator to test In-app Billing; you must install your application on a
    269     device to test In-app Billing.</p>
    270     <p>To learn how to install an application on a device, see <a
    271     href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
    272     device</a>.</p>
    273   </li>
    274   <li><strong>Sign in to your device with your developer account.</strong>
    275     <p>You do not need to use a test account if you are testing only with the reserved product
    276     IDs.</p>
    277   </li>
    278   <li><strong>Verify that your device is running a supported version of the Google Play
    279   application or the MyApps application.</strong>
    280     <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
    281     the MyApps application. If your device is running any other version of Android, In-app Billing
    282     requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
    283     version of the Google Play application, see <a
    284     href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
    285     Play</a>.</p>
    286   </li>
    287   <li><strong>Run your application and purchase the reserved product IDs.</strong></li>
    288 </ol>
    289 
    290 <p class="note"><strong>Note</strong>: Making In-app Billing requests with the reserved product IDs
    291 overrides the usual Google Play production system. When you send an In-app Billing request for a
    292 reserved product ID, the quality of service will not be comparable to the production
    293 environment.</p>
    294 
    295 <h2 id="billing-testing-test">Setting Up for Test Purchases</h2>
    296 
    297 <p>After you finish your static response testing, and you verify that signature verification is
    298 working in your application, you can test your In-app Billing implementation by making actual in-app
    299 purchases. Testing real in-app purchases enables you to test the end-to-end In-app Billing
    300 experience, including the actual purchases from Google Play and the actual checkout flow that
    301 users will experience in your application.</p>
    302 
    303 <p class="note"><strong>Note:</strong> You can do end-to-end testing of your app
    304   by publishing it to an <a
    305   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
    306   distribution channel</a>. This allows you to publish the app to the Google
    307   Play store, but limit its availability to just the testers you designate. </p>
    308 
    309 <p>To test your In-app Billing implementation with actual in-app purchases, you will need to
    310 register at least one test account on the Google Play Developer Console. You cannot use your
    311 developer account to test the complete in-app purchase process because Google payments does not let
    312 you buy items from yourself. If you have not set up test accounts before, see <a
    313 href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">Setting up test
    314 accounts</a>.</p>
    315 
    316 <p>A test account can purchase an item in your product list only if the
    317 item is published.</p>
    318 
    319 <p>To test your In-app Billing implementation with actual purchases, follow these steps:</p>
    320 
    321 <ol>
    322   <li><strong>Upload your application to the <a
    323   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
    324   distribution channel</a> with the Developer Console.</strong>
    325 
    326    <p class="note"><strong>Note:</strong> Previously you could test an app by
    327     uploading an unpublished "draft" version. This functionality is no longer
    328     supported; instead, you must publish it to the alpha or beta distribution
    329     channel. For more information, see <a href="#draft_apps">Draft Apps are No
    330     Longer Supported</a>.
    331 
    332   </li>
    333   <li><strong>Add items to the application's product list.</strong>
    334     <p>Make sure that you publish the items (the application can remain unpublished). See <a
    335     href="{@docRoot}google/play/billing/billing_admin.html#billing-catalog">Creating a product
    336     list</a> to learn how to do this.</p>
    337   </li>
    338   <li><strong>Install your application on an Android-powered device.</strong>
    339     <p>You cannot use the emulator to test In-app Billing; you must install your application on a
    340     device to test In-app Billing.</p>
    341     <p>To learn how to install an application on a device, see <a
    342     href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
    343     device</a>.</p>
    344   </li>
    345   <li><strong>Verify that your device is running a supported version of the Google Play
    346   application or the MyApps application.</strong>
    347     <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
    348     the MyApps application. If your device is running any other version of Android, In-app Billing
    349     requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
    350     version of the Google Play application, see <a
    351     href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
    352     Play</a>.</p>
    353   </li>
    354   <li><strong>Make in-app purchases in your application.</strong></li>
    355 </ol>
    356 
    357 <p class="note"><strong>Note:</strong> The only way to change the primary account on a device is to
    358 do a factory reset, making sure you log on with your primary account first.</p>
    359 
    360 <p>When you are finished testing your In-app Billing implementation, you are ready to
    361 publish your application on Google Play. You can follow the normal steps for <a
    362 href="{@docRoot}tools/publishing/preparing.html">preparing</a>, <a
    363 href="{@docRoot}tools/publishing/app-signing.html">signing</a>, and <a
    364 href="{@docRoot}distribute/tools/launch-checklist.html">publishing on Google Play</a>.
    365 </p>
    366 
    367 <h2 id="draft_apps">Draft Apps are No Longer Supported</h2>
    368 
    369 <p>Previously, you could publish a "draft" version of your app for testing. This
    370 functionality is no longer supported. Instead, there are two ways you can test
    371 how a pre-release app functions on the Google Play store:</p>
    372 
    373 <ul>
    374 
    375   <li>You can publish an app to the <a
    376   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
    377   or beta distribution channels</a>. This makes the app available on the Google
    378   Play store, but only to the testers you put on a "whitelist".</li>
    379 
    380   <li>In a few cases, you can test Google Play functionality with an unpublished
    381   app. For example, you can test an unpublished app's in-app billing support by
    382   using <a
    383   href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-static">static
    384   responses</a>, special reserved product IDs that always return a specific
    385   result (like "purchased" or "refunded").</li>
    386 
    387 </ul>
    388