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