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