docs/html/google/play/billing/billing_testing.jd - platform/frameworks/base - Git at Google

 page.title=Testing In-app Billing
 parent.title=In-app Billing
 parent.link=index.html
 page.tags="inapp, billing, iap"
 @jd:body

 <div id="qv-wrapper">
 <div id="qv">
   <h2>In this document</h2>
   <ol>
     <li><a href="#testing-purchases">Testing In-app Purchases</a></li>
     <li><a href="#billing-testing-static">Testing with Static Responses</a></li>
     <li><a href="#billing-testing-test">Setting Up for Test Purchases</a></li>
     <li><a href="#draft_apps">Draft Apps are No Longer Supported</a></li>
   </ol>
   <h2>See also</h2>
   <ol>
     <li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
     Billing</a></li>
   <ol>
 </div>
 </div>

 <p>The Google Play Developer Console provides several tools that help you test your In-app Billing
 implementation:</p>

 <ul>
 <li>Test purchases, which let license-test users purchase your published in-app
     items, but without any actual charges to their accounts.</li>
 <li>Static billing responses from Google Play, for testing in early development</p>
 </ul>

 <p>To test In-app Billing in an application you must install the application on an Android-powered
 device. You cannot use the Android emulator to test In-app Billing.  The device you use for testing
 must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have
 the most current version of the Google Play application installed. If a device is not running the
 most current Google Play application, your application won't be able to send In-app Billing
 requests to Google Play. For general information about how to set up a device for use in
 developing Android applications, see <a href="{@docRoot}tools/device.html">Using Hardware
 Devices</a>.</p>

 <h2 id="testing-purchases">Testing In-app Purchases</h2>

 <p>When your In-app Billing implementation is ready, you can test purchasing of your in-app SKUs in two ways:</p>

 <ul> <li><strong>Test purchases</strong>, which let your selected license-test
 users purchase your in-app products without any resulting charges to the user.
 Test purchases can be used in alpha/beta releases or in published apps. </li>
 <li><strong>Real purchases</strong>, which let regular users make real purchases
 of your in-app products with actual charges to the user’s payment instruments.
 You can use Google Play’s alpha and beta release groups to manage
 the users who can make live purchases using your implementation.  </li>
 </ul>

 <p>The sections below provide more detail about how to use these approaches for
 testing and validation. </p>

 <h3 id="test-purchases">Test Purchases (In-app Billing Sandbox)</h3>

 <p>Test purchases offer a secure, convenient way to enable larger-scale testing
 of your In-app Billing implementation during development or in preparation for
 launch. They let authorized user accounts make purchases of your in-app products
 through Google Play without incurring any actual charges to the user
 accounts.</p>

 <p>Once authorized for testing access, those users can make purchases without
 being charged.
 Test purchases are real orders and Google Play processes them in the same way as
 other orders. When purchases are complete, Google Play prevents the orders from
 going to financial processing, ensuring that there are no actual charges to user
 accounts, and automatically canceling the completed orders after 14 days. </p>

 <p class="note">
   <strong>Note:</strong> Test subscription purchases recur daily, regardless of
   the product's subscription period.
 </p>

 <h4 id="setup">Setting up test purchases</h4>

 <p>It’s easy to set up test purchases&mdash;any user account can be chosen to be
 a test account, and any user of a test account can make test purchases with any
 available payment method (even though there’s no charge to the payment
 method).</p>

 <p>First, upload and publish in-app products that you want testers to be able to
 purchase. You can upload and publish in-app products in the Developer Console.
 Note that you can upload and publish your in-app items before you publish the
 APK itself.</p>

 <p>Next, create license test accounts for authorized users. In the Developer
 Console, go to <strong>Settings</strong> &gt; <strong>Account details</strong>,
 then in the License Testing section, add the addresses to <strong>Gmail accounts
 with testing access</strong> field. For more information, see <a
 href="#billing-testing-test">Setting Up for Test Purchases</a>.</p>

 <p>Once you’ve added the users as license tester accounts and saved the change,
 within 15 minutes those users can begin making test purchases of your in-app
 products.</p>

 <p class="note"><strong>Note</strong>: To make test purchases, the license test
 account must be on the user’s Android device. If the device has more than one
 account, the purchase will be made with the account that downloaded the app. If
 none of the accounts has downloaded the app, the purchase is made with the first
 account. Users can confirm the account that is making a purchase by expanding the
 purchase dialog.</p>

 <h4 id="tp-account">Test purchases and developer account</h4>
 <p>Authorized license test accounts are associated with your developer account
 in Google Play, rather than with a specific APK or package name. Identifying an
 account as a test account enables it to purchase any of your in-app products
 without being charged. </p>

 <h4 id="purchase-flow">Details of purchase flow</h4>
 <p>During a test purchase, users can test the actual merchandising, purchase,
 and fulfillment flow in your app.  During purchase, the inapp item is displayed
 as a normal item with an actual price. However, Google Play marks test purchases
 with a notice across the center of the purchase dialog, for easy identification.
 </p>

 <h4 id="cancelling">Canceling completed test purchases</h4>
 <p>Google Play accumulates completed test purchases for each user but does not
 pass them on  to financial processing. Over time, it automatically clears out
 the purchases by canceling them. </p>

 <p>In some cases, you might want to manually cancel a test purchase to continue
 testing. For canceling purchases, you have these options:</p>

 <ul>
 <li>Wait for the transactions to expire&mdash;Google Play clears completed test
 purchases 14 days after their purchase date. </li>
 <li>Cancel purchases manually&mdash;you can go to the Google Wallet Merchant
 Center, look up the transaction, and then cancel it. You can find transactions
 by looking up their order numbers.</li>
 </ul>

 <h3 id="transations">Testing with real transactions</h3>
 <p>As you prepare to launch an app that uses In-app Billing, you can make use of
 Google Play alpha/beta release options to do validation and load testing on your
 implementation before distributing the app to all of your users. </p>

 <p>With alpha/beta test groups, real users (chosen by you) can install your app
 from Google Play and test your in-app products. They can make real purchases
 that result in actual charges to their accounts, using any of their normal
 payment methods in Google Play to make purchases. Note that if you include test
 license accounts in your alpha and beta distribution groups, those users will
 only be able to make test purchases. </p>


 <h2 id="billing-testing-static">Testing with Static Responses</h2>

 <p>We recommend that you first test your In-app Billing implementation using static responses from
 Google Play. This enables you to verify that your application is handling the primary Google
 Play responses correctly and that your application is able to verify signatures correctly. You can do this
 even if the app hasn't been published yet.</p>

 <p>To test your implementation with static responses, you make an In-app Billing request using a
 special item that has a reserved product ID. Each reserved product ID returns a specific static
 response from Google Play. No money is transferred when you make In-app Billing requests with the
 reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
 with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
 product ID android.test.purchased.</p>

 <img src="{@docRoot}images/billing_test_flow.png" height="381" id="figure1" />
 <p class="img-caption">
   <strong>Figure 1.</strong>Wallet flow for the special reserved item android.test.purchased.
 </p>

 <p>You do not need to list the reserved products in your application's product list. Google Play
 already knows about the reserved product IDs. Also, you do not need to upload your application to
 the Developer Console to perform static response tests with the reserved product IDs. You can simply
 install your application on a device, log into the device, and make billing requests using the
 reserved product IDs.</p>

 <p class="note"><strong>Note:</strong> Previously you could test an app by
 uploading an unpublished "draft" version. This functionality is no longer
 supported. However, you can test your app with static responses even before you
 upload it to the Google Play store. For more information, see <a
 href="#draft_apps">Draft Apps are No Longer Supported</a>.

 <p>There are four reserved product IDs for testing static In-app Billing responses:</p>

 <ul>
   <li><strong>android.test.purchased</strong>
     <p>When you make an In-app Billing request with this product ID, Google Play responds as
     though you successfully purchased an item. The response includes a JSON string, which contains
     fake purchase information (for example, a fake order ID). In some cases, the JSON string is
     signed and the response includes the signature so you can test your signature verification
     implementation using these responses.</p>
   </li>
   <li><strong>android.test.canceled</strong>
     <p>When you make an In-app Billing request with this product ID Google Play responds as
     though the purchase was canceled. This can occur when an error is encountered in the order
     process, such as an invalid credit card, or when you cancel a user's order before it is
     charged.</p>
   </li>
   <li><strong>android.test.refunded</strong>
     <p>When you make an In-app Billing request with this product ID, Google Play responds as
     though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
     billing service. Refunds must be initiated by you (the merchant). After you process a refund
     request through your Google Wallet merchant account, a refund message is sent to your application by
     Google Play. This occurs only when Google Play gets notification from Google Wallet that
     a refund has been made. For more information about refunds, see <a href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
 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
 Pricing</a>.</p>
   </li>
   <li><strong>android.test.item_unavailable</strong>
     <p>When you make an In-app Billing request with this product ID, Google Play responds as
     though the item being purchased was not listed in your application's product list.</p>
   </li>
 </ul>

 <p>In some cases, the reserved items may return signed static responses, which
 lets you test signature verification in your application. The reserved items
 only return signed responses if the user running the application has a <a
 href="{@docRoot}distribute/googleplay/start.html">developer</a> or <a
 href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test
 account.</a>

 <p>To make an In-app Billing request with a reserved product ID, you simply construct a normal
 <code>REQUEST_PURCHASE</code> request, but instead of using a real product ID from your
 application's product list you use one of the reserved product IDs.</p>

 <p>To test your application using the reserved product IDs, follow these steps:</p>

 <ol>
   <li><strong>Install your application on an Android-powered device.</strong>
     <p>You cannot use the emulator to test In-app Billing; you must install your application on a
     device to test In-app Billing.</p>
     <p>To learn how to install an application on a device, see <a
     href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
     device</a>.</p>
   </li>
   <li><strong>Sign in to your device with your developer account.</strong>
     <p>You do not need to use a test account if you are testing only with the reserved product
     IDs.</p>
   </li>
   <li><strong>Verify that your device is running a supported version of the Google Play
   application or the MyApps application.</strong>
     <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, In-app Billing
     requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
     version of the Google Play application, see <a
     href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
     Play</a>.</p>
   </li>
   <li><strong>Run your application and purchase the reserved product IDs.</strong></li>
 </ol>

 <p class="note"><strong>Note</strong>: Making In-app Billing requests with the reserved product IDs
 overrides the usual Google Play production system. When you send an In-app Billing request for a
 reserved product ID, the quality of service will not be comparable to the production
 environment.</p>

 <h2 id="billing-testing-test">Setting Up for Test Purchases</h2>

 <p>After you finish your static response testing, and you verify that signature verification is
 working in your application, you can test your In-app Billing implementation by making actual in-app
 purchases. Testing real in-app purchases enables you to test the end-to-end In-app Billing
 experience, including the actual purchases from Google Play and the actual checkout flow that
 users will experience in your application.</p>

 <p class="note"><strong>Note:</strong> You can do end-to-end testing of your app
   by publishing it to an <a
   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
   distribution channel</a>. This allows you to publish the app to the Google
   Play store, but limit its availability to just the testers you designate. </p>

 <p>To test your In-app Billing implementation with actual in-app purchases, you will need to
 register at least one test account on the Google Play Developer Console. You cannot use your
 developer account to test the complete in-app purchase process because Google Wallet does not let
 you buy items from yourself. If you have not set up test accounts before, see <a
 href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">Setting up test
 accounts</a>.</p>

 <p>A test account can purchase an item in your product list only if the
 item is published.</p>

 <p>To test your In-app Billing implementation with actual purchases, follow these steps:</p>

 <ol>
   <li><strong>Upload your application to the <a
   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
   distribution channel</a> with the Developer Console.</strong>

    <p class="note"><strong>Note:</strong> Previously you could test an app by
     uploading an unpublished "draft" version. This functionality is no longer
     supported; instead, you must publish it to the alpha or beta distribution
     channel. For more information, see <a href="#draft_apps">Draft Apps are No
     Longer Supported</a>.

   </li>
   <li><strong>Add items to the application's product list.</strong>
     <p>Make sure that you publish the items (the application can remain unpublished). See <a
     href="{@docRoot}google/play/billing/billing_admin.html#billing-catalog">Creating a product
     list</a> to learn how to do this.</p>
   </li>
   <li><strong>Install your application on an Android-powered device.</strong>
     <p>You cannot use the emulator to test In-app Billing; you must install your application on a
     device to test In-app Billing.</p>
     <p>To learn how to install an application on a device, see <a
     href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
     device</a>.</p>
   </li>
   <li><strong>Verify that your device is running a supported version of the Google Play
   application or the MyApps application.</strong>
     <p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
     the MyApps application. If your device is running any other version of Android, In-app Billing
     requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
     version of the Google Play application, see <a
     href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
     Play</a>.</p>
   </li>
   <li><strong>Make in-app purchases in your application.</strong></li>
 </ol>

 <p class="note"><strong>Note:</strong> The only way to change the primary account on a device is to
 do a factory reset, making sure you log on with your primary account first.</p>

 <p>When you are finished testing your In-app Billing implementation, you are ready to
 publish your application on Google Play. You can follow the normal steps for <a
 href="{@docRoot}tools/publishing/preparing.html">preparing</a>, <a
 href="{@docRoot}tools/publishing/app-signing.html">signing</a>, and <a
 href="{@docRoot}distribute/tools/launch-checklist.html">publishing on Google Play</a>.
 </p>

 <h2 id="draft_apps">Draft Apps are No Longer Supported</h2>

 <p>Previously, you could publish a "draft" version of your app for testing. This
 functionality is no longer supported. Instead, there are two ways you can test
 how a pre-release app functions on the Google Play store:</p>

 <ul>

   <li>You can publish an app to the <a
   href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
   or beta distribution channels</a>. This makes the app available on the Google
   Play store, but only to the testers you put on a "whitelist".</li>

   <li>In a few cases, you can test Google Play functionality with an unpublished
   app. For example, you can test an unpublished app's in-app billing support by
   using <a
   href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-static">static
   responses</a>, special reserved product IDs that always return a specific
   result (like "purchased" or "refunded").</li>

 </ul>
	page.title=Testing In-app Billing
	parent.title=In-app Billing
	parent.link=index.html
	page.tags="inapp, billing, iap"
	@jd:body

	<div id="qv-wrapper">
	<div id="qv">
	<h2>In this document</h2>
	<ol>
	<li><a href="#testing-purchases">Testing In-app Purchases</a></li>
	<li><a href="#billing-testing-static">Testing with Static Responses</a></li>
	<li><a href="#billing-testing-test">Setting Up for Test Purchases</a></li>
	<li><a href="#draft_apps">Draft Apps are No Longer Supported</a></li>
	</ol>
	<h2>See also</h2>
	<ol>
	<li><a href="{@docRoot}google/play/billing/billing_overview.html">Overview of In-app
	Billing</a></li>
	<ol>
	</div>
	</div>

	<p>The Google Play Developer Console provides several tools that help you test your In-app Billing
	implementation:</p>

	<ul>
	<li>Test purchases, which let license-test users purchase your published in-app
	items, but without any actual charges to their accounts.</li>
	<li>Static billing responses from Google Play, for testing in early development</p>
	</ul>

	<p>To test In-app Billing in an application you must install the application on an Android-powered
	device. You cannot use the Android emulator to test In-app Billing. The device you use for testing
	must run a standard version of the Android 1.6 or later platform (API level 4 or higher), and have
	the most current version of the Google Play application installed. If a device is not running the
	most current Google Play application, your application won't be able to send In-app Billing
	requests to Google Play. For general information about how to set up a device for use in
	developing Android applications, see <a href="{@docRoot}tools/device.html">Using Hardware
	Devices</a>.</p>

	<h2 id="testing-purchases">Testing In-app Purchases</h2>

	<p>When your In-app Billing implementation is ready, you can test purchasing of your in-app SKUs in two ways:</p>

	<ul> <li><strong>Test purchases</strong>, which let your selected license-test
	users purchase your in-app products without any resulting charges to the user.
	Test purchases can be used in alpha/beta releases or in published apps. </li>
	<li><strong>Real purchases</strong>, which let regular users make real purchases
	of your in-app products with actual charges to the user’s payment instruments.
	You can use Google Play’s alpha and beta release groups to manage
	the users who can make live purchases using your implementation. </li>
	</ul>

	<p>The sections below provide more detail about how to use these approaches for
	testing and validation. </p>

	<h3 id="test-purchases">Test Purchases (In-app Billing Sandbox)</h3>

	<p>Test purchases offer a secure, convenient way to enable larger-scale testing
	of your In-app Billing implementation during development or in preparation for
	launch. They let authorized user accounts make purchases of your in-app products
	through Google Play without incurring any actual charges to the user
	accounts.</p>

	<p>Once authorized for testing access, those users can make purchases without
	being charged.
	Test purchases are real orders and Google Play processes them in the same way as
	other orders. When purchases are complete, Google Play prevents the orders from
	going to financial processing, ensuring that there are no actual charges to user
	accounts, and automatically canceling the completed orders after 14 days. </p>

	<p class="note">
	<strong>Note:</strong> Test subscription purchases recur daily, regardless of
	the product's subscription period.
	</p>

	<h4 id="setup">Setting up test purchases</h4>

	<p>It’s easy to set up test purchases—any user account can be chosen to be
	a test account, and any user of a test account can make test purchases with any
	available payment method (even though there’s no charge to the payment
	method).</p>

	<p>First, upload and publish in-app products that you want testers to be able to
	purchase. You can upload and publish in-app products in the Developer Console.
	Note that you can upload and publish your in-app items before you publish the
	APK itself.</p>

	<p>Next, create license test accounts for authorized users. In the Developer
	Console, go to <strong>Settings</strong> > <strong>Account details</strong>,
	then in the License Testing section, add the addresses to <strong>Gmail accounts
	with testing access</strong> field. For more information, see <a
	href="#billing-testing-test">Setting Up for Test Purchases</a>.</p>

	<p>Once you’ve added the users as license tester accounts and saved the change,
	within 15 minutes those users can begin making test purchases of your in-app
	products.</p>

	<p class="note"><strong>Note</strong>: To make test purchases, the license test
	account must be on the user’s Android device. If the device has more than one
	account, the purchase will be made with the account that downloaded the app. If
	none of the accounts has downloaded the app, the purchase is made with the first
	account. Users can confirm the account that is making a purchase by expanding the
	purchase dialog.</p>

	<h4 id="tp-account">Test purchases and developer account</h4>
	<p>Authorized license test accounts are associated with your developer account
	in Google Play, rather than with a specific APK or package name. Identifying an
	account as a test account enables it to purchase any of your in-app products
	without being charged. </p>

	<h4 id="purchase-flow">Details of purchase flow</h4>
	<p>During a test purchase, users can test the actual merchandising, purchase,
	and fulfillment flow in your app. During purchase, the inapp item is displayed
	as a normal item with an actual price. However, Google Play marks test purchases
	with a notice across the center of the purchase dialog, for easy identification.
	</p>

	<h4 id="cancelling">Canceling completed test purchases</h4>
	<p>Google Play accumulates completed test purchases for each user but does not
	pass them on to financial processing. Over time, it automatically clears out
	the purchases by canceling them. </p>

	<p>In some cases, you might want to manually cancel a test purchase to continue
	testing. For canceling purchases, you have these options:</p>

	<ul>
	<li>Wait for the transactions to expire—Google Play clears completed test
	purchases 14 days after their purchase date. </li>
	<li>Cancel purchases manually—you can go to the Google Wallet Merchant
	Center, look up the transaction, and then cancel it. You can find transactions
	by looking up their order numbers.</li>
	</ul>

	<h3 id="transations">Testing with real transactions</h3>
	<p>As you prepare to launch an app that uses In-app Billing, you can make use of
	Google Play alpha/beta release options to do validation and load testing on your
	implementation before distributing the app to all of your users. </p>

	<p>With alpha/beta test groups, real users (chosen by you) can install your app
	from Google Play and test your in-app products. They can make real purchases
	that result in actual charges to their accounts, using any of their normal
	payment methods in Google Play to make purchases. Note that if you include test
	license accounts in your alpha and beta distribution groups, those users will
	only be able to make test purchases. </p>


	<h2 id="billing-testing-static">Testing with Static Responses</h2>

	<p>We recommend that you first test your In-app Billing implementation using static responses from
	Google Play. This enables you to verify that your application is handling the primary Google
	Play responses correctly and that your application is able to verify signatures correctly. You can do this
	even if the app hasn't been published yet.</p>

	<p>To test your implementation with static responses, you make an In-app Billing request using a
	special item that has a reserved product ID. Each reserved product ID returns a specific static
	response from Google Play. No money is transferred when you make In-app Billing requests with the
	reserved product IDs. Also, you cannot specify the form of payment when you make a billing request
	with a reserved product ID. Figure 1 shows the checkout flow for the reserved item that has the
	product ID android.test.purchased.</p>

	<img src="{@docRoot}images/billing_test_flow.png" height="381" id="figure1" />
	<p class="img-caption">
	<strong>Figure 1.</strong>Wallet flow for the special reserved item android.test.purchased.
	</p>

	<p>You do not need to list the reserved products in your application's product list. Google Play
	already knows about the reserved product IDs. Also, you do not need to upload your application to
	the Developer Console to perform static response tests with the reserved product IDs. You can simply
	install your application on a device, log into the device, and make billing requests using the
	reserved product IDs.</p>

	<p class="note"><strong>Note:</strong> Previously you could test an app by
	uploading an unpublished "draft" version. This functionality is no longer
	supported. However, you can test your app with static responses even before you
	upload it to the Google Play store. For more information, see <a
	href="#draft_apps">Draft Apps are No Longer Supported</a>.

	<p>There are four reserved product IDs for testing static In-app Billing responses:</p>

	<ul>
	<li><strong>android.test.purchased</strong>
	<p>When you make an In-app Billing request with this product ID, Google Play responds as
	though you successfully purchased an item. The response includes a JSON string, which contains
	fake purchase information (for example, a fake order ID). In some cases, the JSON string is
	signed and the response includes the signature so you can test your signature verification
	implementation using these responses.</p>
	</li>
	<li><strong>android.test.canceled</strong>
	<p>When you make an In-app Billing request with this product ID Google Play responds as
	though the purchase was canceled. This can occur when an error is encountered in the order
	process, such as an invalid credit card, or when you cancel a user's order before it is
	charged.</p>
	</li>
	<li><strong>android.test.refunded</strong>
	<p>When you make an In-app Billing request with this product ID, Google Play responds as
	though the purchase was refunded. Refunds cannot be initiated through Google Play's in-app
	billing service. Refunds must be initiated by you (the merchant). After you process a refund
	request through your Google Wallet merchant account, a refund message is sent to your application by
	Google Play. This occurs only when Google Play gets notification from Google Wallet that
	a refund has been made. For more information about refunds, see <a href="{@docRoot}google/play/billing/v2/api.html#billing-action-notify">Handling
	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
	Pricing</a>.</p>
	</li>
	<li><strong>android.test.item_unavailable</strong>
	<p>When you make an In-app Billing request with this product ID, Google Play responds as
	though the item being purchased was not listed in your application's product list.</p>
	</li>
	</ul>

	<p>In some cases, the reserved items may return signed static responses, which
	lets you test signature verification in your application. The reserved items
	only return signed responses if the user running the application has a <a
	href="{@docRoot}distribute/googleplay/start.html">developer</a> or <a
	href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">test
	account.</a>

	<p>To make an In-app Billing request with a reserved product ID, you simply construct a normal
	<code>REQUEST_PURCHASE</code> request, but instead of using a real product ID from your
	application's product list you use one of the reserved product IDs.</p>

	<p>To test your application using the reserved product IDs, follow these steps:</p>

	<ol>
	<li><strong>Install your application on an Android-powered device.</strong>
	<p>You cannot use the emulator to test In-app Billing; you must install your application on a
	device to test In-app Billing.</p>
	<p>To learn how to install an application on a device, see <a
	href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
	device</a>.</p>
	</li>
	<li><strong>Sign in to your device with your developer account.</strong>
	<p>You do not need to use a test account if you are testing only with the reserved product
	IDs.</p>
	</li>
	<li><strong>Verify that your device is running a supported version of the Google Play
	application or the MyApps application.</strong>
	<p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
	the MyApps application. If your device is running any other version of Android, In-app Billing
	requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
	version of the Google Play application, see <a
	href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
	Play</a>.</p>
	</li>
	<li><strong>Run your application and purchase the reserved product IDs.</strong></li>
	</ol>

	<p class="note"><strong>Note</strong>: Making In-app Billing requests with the reserved product IDs
	overrides the usual Google Play production system. When you send an In-app Billing request for a
	reserved product ID, the quality of service will not be comparable to the production
	environment.</p>

	<h2 id="billing-testing-test">Setting Up for Test Purchases</h2>

	<p>After you finish your static response testing, and you verify that signature verification is
	working in your application, you can test your In-app Billing implementation by making actual in-app
	purchases. Testing real in-app purchases enables you to test the end-to-end In-app Billing
	experience, including the actual purchases from Google Play and the actual checkout flow that
	users will experience in your application.</p>

	<p class="note"><strong>Note:</strong> You can do end-to-end testing of your app
	by publishing it to an <a
	href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
	distribution channel</a>. This allows you to publish the app to the Google
	Play store, but limit its availability to just the testers you designate. </p>

	<p>To test your In-app Billing implementation with actual in-app purchases, you will need to
	register at least one test account on the Google Play Developer Console. You cannot use your
	developer account to test the complete in-app purchase process because Google Wallet does not let
	you buy items from yourself. If you have not set up test accounts before, see <a
	href="{@docRoot}google/play/billing/billing_admin.html#billing-testing-setup">Setting up test
	accounts</a>.</p>

	<p>A test account can purchase an item in your product list only if the
	item is published.</p>

	<p>To test your In-app Billing implementation with actual purchases, follow these steps:</p>

	<ol>
	<li><strong>Upload your application to the <a
	href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
	distribution channel</a> with the Developer Console.</strong>

	<p class="note"><strong>Note:</strong> Previously you could test an app by
	uploading an unpublished "draft" version. This functionality is no longer
	supported; instead, you must publish it to the alpha or beta distribution
	channel. For more information, see <a href="#draft_apps">Draft Apps are No
	Longer Supported</a>.

	</li>
	<li><strong>Add items to the application's product list.</strong>
	<p>Make sure that you publish the items (the application can remain unpublished). See <a
	href="{@docRoot}google/play/billing/billing_admin.html#billing-catalog">Creating a product
	list</a> to learn how to do this.</p>
	</li>
	<li><strong>Install your application on an Android-powered device.</strong>
	<p>You cannot use the emulator to test In-app Billing; you must install your application on a
	device to test In-app Billing.</p>
	<p>To learn how to install an application on a device, see <a
	href="{@docRoot}tools/building/building-cmdline.html#RunningOnDevice">Running on a
	device</a>.</p>
	</li>
	<li><strong>Verify that your device is running a supported version of the Google Play
	application or the MyApps application.</strong>
	<p>If your device is running Android 3.0, In-app Billing requires version 5.0.12 (or higher) of
	the MyApps application. If your device is running any other version of Android, In-app Billing
	requires version 2.3.4 (or higher) of the Google Play application. To learn how to check the
	version of the Google Play application, see <a
	href="http://market.android.com/support/bin/answer.py?answer=190860">Updating Google
	Play</a>.</p>
	</li>
	<li><strong>Make in-app purchases in your application.</strong></li>
	</ol>

	<p class="note"><strong>Note:</strong> The only way to change the primary account on a device is to
	do a factory reset, making sure you log on with your primary account first.</p>

	<p>When you are finished testing your In-app Billing implementation, you are ready to
	publish your application on Google Play. You can follow the normal steps for <a
	href="{@docRoot}tools/publishing/preparing.html">preparing</a>, <a
	href="{@docRoot}tools/publishing/app-signing.html">signing</a>, and <a
	href="{@docRoot}distribute/tools/launch-checklist.html">publishing on Google Play</a>.
	</p>

	<h2 id="draft_apps">Draft Apps are No Longer Supported</h2>

	<p>Previously, you could publish a "draft" version of your app for testing. This
	functionality is no longer supported. Instead, there are two ways you can test
	how a pre-release app functions on the Google Play store:</p>

	<ul>

	<li>You can publish an app to the <a
	href="{@docRoot}distribute/googleplay/developer-console.html#alpha-beta">alpha
	or beta distribution channels</a>. This makes the app available on the Google
	Play store, but only to the testers you put on a "whitelist".</li>

	<li>In a few cases, you can test Google Play functionality with an unpublished
	app. For example, you can test an unpublished app's in-app billing support by
	using <a
	href="{@docRoot}google/play/billing/billing_testing.html#billing-testing-static">static
	responses</a>, special reserved product IDs that always return a specific
	result (like "purchased" or "refunded").</li>

	</ul>