| 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, 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, you need to publish your app to an <a |
| href="https://support.google.com/googleplay/android-developer/answer/3131213">alpha |
| or beta channel in Google Play.</a></p> |
| |
| <p>After you publish an app to an alpha or beta channel, it can take a few hours |
| for the app to be available for testers. The version code of an APK on a test device |
| must match the version currently uploaded to the alpha or beta channel on Google Play.</p> |
| |
| <p class="caution"><strong>Important</strong>: To test in-app products or make in-app |
| purchases in your alpha or beta channel app, each tester |
| needs to <a href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in |
| to your app’s alpha or beta test</a>. On your test’s opt-in URL, your |
| testers will get an explanation of what it means to be a tester and a link to opt-in.</p> |
| |
| <p>You can test on any Android-powered hardware device running Android 1.6 or higher. |
| The most current version of the Google Play application must be installed on the device. |
| 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 only. </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.</li> |
| </ul> |
| |
| <p>In either case, you need to publish your app to Google Play's |
| <a href="https://support.google.com/googleplay/android-developer/answer/3131213">alpha |
| and beta release channels</a> to manage the users who can make purchases.</p> |
| |
| <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. The <code>orderId</code> field for test purchases remains |
| blank, ensuring that there are no actual charges to user accounts. |
| </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="caution"><strong>Important</strong>: After you publish your app |
| to an alpha or beta channel, your testers need to <a |
| href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in |
| to your app’s alpha or beta test</a> using the provided opt-in URL before they |
| can make test purchases. </p> |
| |
| <p class="note"><strong>Note</strong>: License test accounts |
| 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> |
| |
| <p class="note"> |
| <strong>Note:</strong> For test purchases, leave the {@code orderId} field |
| blank. You can use the {@code purchaseToken} field to identify test purchases. |
| </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.</p> |
| |
| <p>In some cases, you might want to manually cancel a test purchase to continue |
| testing. To do so, open the app page in the Play Store. If the test purchase |
| that you want to cancel is a subscription, you can also use the |
| <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/cancel"> |
| {@code cancel()}</a> method of the Purchases.subscriptions API. |
| </ul> |
| |
| <p class="caution"> |
| <strong>Important:</strong> The |
| <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/refund"> |
| {@code refund()}</a> and |
| <a href="https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/revoke"> |
| {@code revoke()}</a> methods of the Purchases.subscriptions API don't support |
| test purchases. |
| </p> |
| |
| |
| <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> |
| |
| <p class="caution"><strong>Important</strong>: After you publish your app |
| to an alpha or beta channel, your testers need to <a |
| href="https://support.google.com/googleplay/android-developer/answer/3131213">opt-in |
| to your app’s alpha or beta test</a> using the provided opt-in URL before they |
| can 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>Purchase 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 payments merchant account, a refund message is sent to your application by |
| Google Play. This occurs only when Google Play gets notification from Google payments 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 payments 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> |