1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
|
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 test account users make real purchase your published in-app items,
but without any actual charges to the user 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 before the app is published, but without any
resulting charges to the user, and </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.
In this case, 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 while the app is still unpublished, without incurring any
actual charges to the user accounts.</p>
<p>Once authorized with testing access, those users can side-load your app and
test the full merchandising, purchase, and fulfillment flow for your products.
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>
<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. You can then distribute your app to your testers and provide a means
of getting feedback. </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">Cancelling 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 cancelling them. </p>
<p>In some cases, you might want to manually cancel a test purchase to continue
testing. For cancelling 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>
<h4 id="requirements">Requirements for using test purchases</h4>
<p>If you plan to use test purchases, please note the requirements and limitations below: </p>
<ul>
<li>Test purchases is only supported for license test accounts when the app is using the In-app Billing v3 API.</li>
<li>Test purchases are only supported for in-app products, not for in-app subscriptions.</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>Also, a test account can purchase an item in your product list only if the item is published. The
application does not need to be published, but the item does need to be 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>
|