1page.title=In-app Billing Reference <span style="font-size:16px;">(IAB Version 2)</span> 2@jd:body 3 4<div style="background-color:#fffdeb;width:100%;margin-bottom:1em;padding:.5em;">In-app Billing Version 2 is superseded. Please <a href="{@docRoot}google/play/billing/billing_overview.html#migration">migrate to Version 3</a> at your earliest convenience.</div> 5 <div id="qv-wrapper" style="margin-top:0;"> 6<div id="qv"> 7<h2>In this document</h2> 8 <ol> 9 <li><a href="#billing-codes">Server Response Codes</a></li> 10 <li><a href="#billing-interface">API Reference</a></li> 11 <li><a href="#billing-intents">Broadcast Intents</a></li> 12 <li><a href="#http-api">REST API for Subscriptions</a></li> 13 </ol> 14 15<h2>Related Samples</h2> 16 <ol> 17 <li><a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">Sample 18 Application (V2)</a></li> 19 </ol> 20 21</div> 22</div> 23<p>This documentation provides technical reference information for using the In-app Billing Version 2 API. </p> 24 25<h2 id="billing-codes">Server Response Codes</h2> 26<p>The following table lists all of the server response codes that are sent from Google Play to 27your application. Google Play sends these response codes asynchronously as 28<code>response_code</code> extras in the <code>com.android.vending.billing.RESPONSE_CODE</code> 29broadcast intent. Your application must handle all of these response codes.</p> 30 31<p class="table-caption" id="response-codes-table"><strong>Table 6.</strong> Summary of response 32codes returned by Google Play.</p> 33 34<table> 35<tr> 36<th>Response Code</th> 37<th>Value</th> 38<th>Description</th> 39</tr> 40<tr> 41 <td><code>RESULT_OK</code></td> 42 <td>0</td> 43 <td>Indicates that the request was sent to the server successfully. When this code is returned in 44 response to a <code>CHECK_BILLING_SUPPORTED</code> request, indicates that billing is 45 supported.</td> 46</tr> 47<tr> 48 <td><code>RESULT_USER_CANCELED</code></td> 49 <td>1</td> 50 <td>Indicates that the user pressed the back button on the checkout page instead of buying the 51 item.</td> 52</tr> 53<tr> 54 <td><code>RESULT_SERVICE_UNAVAILABLE</code></td> 55 <td>2</td> 56 <td>Indicates that the network connection is down.</td> 57</tr> 58<tr> 59 <td><code>RESULT_BILLING_UNAVAILABLE</code></td> 60 <td>3</td> 61 <td>Indicates that In-app Billing is not available because the <code>API_VERSION</code> that you 62 specified is not recognized by the Google Play application or the user is ineligible for in-app 63 billing (for example, the user resides in a country that prohibits in-app purchases).</td> 64</tr> 65<tr> 66 <td><code>RESULT_ITEM_UNAVAILABLE</code></td> 67 <td>4</td> 68 <td>Indicates that Google Play cannot find the requested item in the application's product 69 list. This can happen if the product ID is misspelled in your <code>REQUEST_PURCHASE</code> 70 request or if an item is unpublished in the application's product list.</td> 71</tr> 72<tr> 73 <td><code>RESULT_DEVELOPER_ERROR</code></td> 74 <td>5</td> 75 <td>Indicates that an application is trying to make an In-app Billing request but the application 76 has not declared the com.android.vending.BILLING permission in its manifest. Can also indicate 77 that an application is not properly signed, or that you sent a malformed request, such as a 78 request with missing Bundle keys or a request that uses an unrecognized request type.</td> 79</tr> 80<tr> 81 <td><code>RESULT_ERROR</code></td> 82 <td>6</td> 83 <td>Indicates an unexpected server error. For example, this error is triggered if you try to 84purchase an item from yourself, which is not allowed by Google Wallet.</td> 85</tr> 86</table> 87</p> 88 89<h3 id="billing-interface">In-app billing Version 2 API reference</h3> 90 91<p>The following section describes the interface for Google Play's In-app Billing service. The 92interface is defined in the <code>IMarketBillingService.aidl</code> file, which is included with the 93In-app Billing <a 94href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">sample 95application</a>.</p> 96<p>The interface consists of a single request method <code>sendBillingRequest()</code>. This method 97takes a single {@link android.os.Bundle} parameter. The Bundle parameter includes several key-value 98pairs, which are summarized in table 7.</p> 99 100<p class="table-caption"><strong>Table 7.</strong> Description of Bundle keys passed in a 101<code>sendBillingRequest()</code> request.</p> 102 103<table> 104 105<tr> 106<th>Key</th> 107<th>Type</th> 108<th>Possible Values</th> 109<th>Required?</th> 110<th>Description</th> 111</tr> 112<tr> 113 <td><code>BILLING_REQUEST</code></td> 114 <td><code>String</code></td> 115 <td><code>CHECK_BILLING_SUPPORTED</code>, <code>REQUEST_PURCHASE</code>, 116 <code>GET_PURCHASE_INFORMATION</code>, <code>CONFIRM_NOTIFICATIONS</code>, or 117 <code>RESTORE_TRANSACTIONS</code></td> 118 <td>Yes</td> 119 <td>The type of billing request you are making with the <code>sendBillingRequest()</code> request. 120 The possible values are discussed more below this table.</td> 121</tr> 122<tr> 123 <td><code>API_VERSION</code></td> 124 <td><code>int</code></td> 125 <td> <ul> 126 <li><code>"2"</code> [<a href="#version_2">details</a>]</li> 127 <li><code>"1"</code> [<a href="#version_1">details</a>]</li> 128 </ul></td> 129 <td>Yes</td> 130 <td>The version of Google Play's In-app Billing service you want to use.</td> 131</tr> 132<tr> 133 <td><code>PACKAGE_NAME</code></td> 134 <td><code>String</code></td> 135 <td>A valid package name.</td> 136 <td>Yes</td> 137 <td>The name of the application that is making the request.</td> 138</tr> 139<tr> 140 <td><code>ITEM_ID</code></td> 141 <td><code>String</code></td> 142 <td>Any valid product identifier.</td> 143 <td>Required for <code>REQUEST_PURCHASE</code> requests.</td> 144 <td>The product ID of the item you are making a billing request for. Every in-app item that you 145 sell using Google Play's In-app Billing service must have a unique product ID, which you 146 specify on the Google Play publisher site.</td> 147</tr> 148<tr> 149 <td><code>NONCE</code></td> 150 <td><code>long</code></td> 151 <td>Any valid <code>long</code> value.</td> 152 <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> 153 requests.</td> 154 <td>A number used once. Your application must generate and send a nonce with each 155 <code>GET_PURCHASE_INFORMATION</code> and <code>RESTORE_TRANSACTIONS</code> request. The nonce is 156 returned with the <code>PURCHASE_STATE_CHANGED</code> broadcast intent, so you can use this value 157 to verify the integrity of transaction responses form Google Play.</td> 158</tr> 159<tr> 160 <td><code>NOTIFY_IDS</code></td> 161 <td>Array of <code>long</code> values</td> 162 <td>Any valid array of <code>long</code> values</td> 163 <td>Required for <code>GET_PURCHASE_INFORMATION</code> and <code>CONFIRM_NOTIFICATIONS</code> 164 requests.</td> 165 <td>An array of notification identifiers. A notification ID is sent to your application in an 166 <code>IN_APP_NOTIFY</code> broadcast intent every time a purchase changes state. You use the 167 notification to retrieve the details of the purchase state change.</td> 168</tr> 169<tr> 170 <td><code>DEVELOPER_PAYLOAD</code></td> 171 <td><code>String</code></td> 172 <td>Any valid <code>String</code> less than 256 characters long.</td> 173 <td>No</td> 174 <td>A developer-specified string that can be specified when you make a 175 <code>REQUEST_PURCHASE</code> request. This field is returned in the JSON string that contains 176 transaction information for an order. You can use this key to send supplemental information with 177 an order. For example, you can use this key to send index keys with an order, which is useful if 178 you are using a database to store purchase information. We recommend that you do not use this key 179 to send data or content.</td> 180</tr> 181</table> 182 183<p>The <code>BILLING_REQUEST</code> key can have the following values:</p> 184 185<ul> 186 <li><code>CHECK_BILLING_SUPPORTED</code> 187 <p>This request verifies that the Google Play application supports In-app Billing. You 188 usually send this request when your application first starts up. This request is useful if you 189 want to enable or disable certain UI features that are relevant only to In-app Billing.</p> 190 </li> 191 <li><code>REQUEST_PURCHASE</code> 192 <p>This request sends a purchase message to the Google Play application and is the foundation 193 of In-app Billing. You send this request when a user indicates that he or she wants to purchase 194 an item in your application. Google Play then handles the financial transaction by displaying 195 the checkout user interface.</p> 196 </li> 197 <li><code>GET_PURCHASE_INFORMATION</code> 198 <p>This request retrieves the details of a purchase state change. A purchase state change can 199 occur when a purchase request is billed successfully or when a user cancels a transaction during 200 checkout. It can also occur when a previous purchase is refunded. Google Play notifies your 201 application when a purchase changes state, so you only need to send this request when there is 202 transaction information to retrieve.</p> 203 </li> 204 <li><code>CONFIRM_NOTIFICATIONS</code> 205 <p>This request acknowledges that your application received the details of a purchase state 206 change. That is, this message confirms that you sent a <code>GET_PURCHASE_INFORMATION</code> 207 request for a given notification and that you received the purchase information for the 208 notification.</p> 209 </li> 210 <li><code>RESTORE_TRANSACTIONS</code> 211 <p>This request retrieves a user's transaction status for managed purchases (see <a 212 href="{@docRoot}google/play/billing/billing_admin.html#billing-purchase-type">Choosing a 213 Purchase Type</a> for more information). You should send this message only when you need to 214 retrieve a user's transaction status, which is usually only when your application is reinstalled 215 or installed for the first time on a device.</p> 216 </li> 217</ul> 218 219<p>Every In-app Billing request generates a synchronous response. The response is a {@link 220android.os.Bundle} and can include one or more of the following keys:</p> 221 222<ul> 223 <li><code>RESPONSE_CODE</code> 224 <p>This key provides status information and error information about a request.</p> 225 </li> 226 <li><code>PURCHASE_INTENT</code> 227 <p>This key provides a {@link android.app.PendingIntent}, which you use to launch the checkout 228 activity.</p> 229 </li> 230 <li><code>REQUEST_ID</code> 231 <p>This key provides you with a request identifier, which you can use to match asynchronous 232 responses with requests.</p> 233 </li> 234</ul> 235 236<p>Some of these keys are not relevant to certain types of requests. Table 8 shows which keys are 237returned for each request type.</p> 238 239<p class="table-caption"><strong>Table 8.</strong> Description of Bundle keys that are returned with 240each In-app Billing request type.</p> 241 242<table> 243 244<tr> 245<th>Request Type</th> 246<th>Keys Returned</th> 247<th>Possible Response Codes</th> 248</tr> 249<tr> 250 <td><code>CHECK_BILLING_SUPPORTED</code></td> 251 <td><code>RESPONSE_CODE</code></td> 252 <td><code>RESULT_OK</code>, <code>RESULT_BILLING_UNAVAILABLE</code>, <code>RESULT_ERROR</code>, 253 <code>RESULT_DEVELOPER_ERROR</code></td> 254</tr> 255<tr> 256 <td><code>REQUEST_PURCHASE</code></td> 257 <td><code>RESPONSE_CODE</code>, <code>PURCHASE_INTENT</code>, <code>REQUEST_ID</code></td> 258 <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td> 259</tr> 260<tr> 261 <td><code>GET_PURCHASE_INFORMATION</code></td> 262 <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td> 263 <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td> 264</tr> 265<tr> 266 <td><code>CONFIRM_NOTIFICATIONS</code></td> 267 <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td> 268 <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td> 269</tr> 270<tr> 271 <td><code>RESTORE_TRANSACTIONS</code></td> 272 <td><code>RESPONSE_CODE</code>, <code>REQUEST_ID</code></td> 273 <td><code>RESULT_OK</code>, <code>RESULT_ERROR</code>, <code>RESULT_DEVELOPER_ERROR</code></td> 274</tr> 275</table> 276 277<h3 id="billing-intents">In-app billing broadcast intents</h3> 278 279<p>The following section describes the In-app Billing broadcast intents that are sent by the Google 280Play application. These broadcast intents inform your application about In-app Billing actions 281that have occurred. Your application must implement a {@link android.content.BroadcastReceiver} to 282receive these broadcast intents, such as the <code>BillingReceiver</code> that's shown in the in-app 283billing <a href="{@docRoot}google/play/billing/v2/billing_integrate.html#billing-download">sample 284application</a>.</p> 285 286<h4>com.android.vending.billing.RESPONSE_CODE</h4> 287 288<p>This broadcast intent contains a Google Play response code, and is sent after you make an 289In-app Billing request. A server response code can indicate that a billing request was successfully 290sent to Google Play or it can indicate that some error occurred during a billing request. This 291intent is not used to report any purchase state changes (such as refund or purchase information). 292For more information about the response codes that are sent with this response, see <a 293href="#billing-codes">Google Play Response Codes for In-app Billing</a>. The sample application 294assigns this broadcast intent to a constant named <code>ACTION_RESPONSE_CODE</code>.</p> 295 296<h5>Extras</h5> 297 298<ul type="none"> 299 <li><code>request_id</code>—a <code>long</code> representing a request ID. A request ID 300 identifies a specific billing request and is returned by Google Play at the time a request is 301 made.</li> 302 <li><code>response_code</code>—an <code>int</code> representing the Google Play server 303 response code.</li> 304</ul> 305 306<h4>com.android.vending.billing.IN_APP_NOTIFY</h4> 307 308<p>This response indicates that a purchase has changed state, which means a purchase succeeded, was 309canceled, or was refunded. This response contains one or more notification IDs. Each notification ID 310corresponds to a specific server-side message, and each messages contains information about one or 311more transactions. After your application receives an <code>IN_APP_NOTIFY</code> broadcast intent, 312you send a <code>GET_PURCHASE_INFORMATION</code> request with the notification IDs to retrieve the 313message details. The sample application assigns this broadcast intent to a constant named 314<code>ACTION_NOTIFY</code>.</p> 315 316<h5>Extras</h5> 317 318<ul type="none"> 319 <li><code>notification_id</code>—a <code>String</code> representing the notification ID for 320 a given purchase state change. Google Play notifies you when there is a purchase state change 321 and the notification includes a unique notification ID. To get the details of the purchase state 322 change, you send the notification ID with the <code>GET_PURCHASE_INFORMATION</code> request.</li> 323</ul> 324 325<h4>com.android.vending.billing.PURCHASE_STATE_CHANGED</h4> 326 327<p>This broadcast intent contains detailed information about one or more transactions. The 328transaction information is contained in a JSON string. The JSON string is signed and the signature 329is sent to your application along with the JSON string (unencrypted). To help ensure the security of 330your In-app Billing messages, your application can verify the signature of this JSON string. The 331sample application assigns this broadcast intent to a constant named 332<code>ACTION_PURCHASE_STATE_CHANGED</code>.</p> 333 334<h5>Extras</h5> 335 336<ul type="none"> 337 <li><code>inapp_signed_data</code>—a <code>String</code> representing the signed JSON 338 string.</li> 339 <li><code>inapp_signature</code>—a <code>String</code> representing the signature.</li> 340</ul> 341 342<p class="note"><strong>Note:</strong> Your application should map the broadcast intents and extras 343to constants that are unique to your application. See the <code>Consts.java</code> file in the 344sample application to see how this is done.</p> 345 346<p>The fields in the JSON string are described in the following table (see table 9):</p> 347 348<p class="table-caption"><strong>Table 9.</strong> Description of JSON fields that are returned with 349a <code>PURCHASE_STATE_CHANGED</code> intent.</p> 350 351<table> 352 353<tr> 354<th>Field</th> 355<th>Description</th> 356</tr> 357<tr> 358 <td>nonce</td> 359 <td>A number used once. Your application generates the nonce and sends it with the 360 <code>GET_PURCHASE_INFORMATION</code> request. Google Play sends the nonce back as part of the 361 JSON string so you can verify the integrity of the message.</td> 362</tr> 363<tr> 364 <td>notificationId</td> 365 <td>A unique identifier that is sent with an <code>IN_APP_NOTIFY</code> broadcast intent. Each 366 <code>notificationId</code> corresponds to a specify message that is waiting to be retrieved on 367 the Google Play server. Your application sends back the <code>notificationId</code> with the 368 <code>GET_PURCHASE_INFORMATION</code> message so Google Play can determine which messages you 369 are retrieving.</td> 370</tr> 371<tr> 372 <td>orderId</td> 373 <td>A unique order identifier for the transaction. This corresponds to the Google Wallet Order 374 ID.</td> 375</tr> 376<tr> 377 <td>packageName</td> 378 <td>The application package from which the purchase originated.</td> 379</tr> 380<tr> 381 <td>productId</td> 382 <td>The item's product identifier. Every item has a product ID, which you must specify in the 383 application's product list on the Google Play publisher site.</td> 384</tr> 385<tr> 386 <td>purchaseTime</td> 387 <td>The time the product was purchased, in milliseconds since the epoch (Jan 1, 1970).</td> 388</tr> 389 390<tr> 391 <td>purchaseState</td> 392 <td>The purchase state of the order. Possible values are 0 (purchased), 1 (canceled), 2 393 (refunded), or 3 (expired, for subscription purchases only).</td> 394</tr> 395<tr> 396 <td>purchaseToken</td> 397 <td>A token that uniquely identifies a subscription purchase for a given item and user pair. 398 You can use the token to specify the subscription when querying for subscription validity. 399 400 <p><br><em>Supported only in In-app Billing API Version 2 and higher.</em></p></td> 401</tr> 402<tr> 403 <td>developerPayload</td> 404 <td>A developer-specified string that contains supplemental information about an order. You can 405 specify a value for this field when you make a <code>REQUEST_PURCHASE</code> request.</td> 406</tr> 407</table> 408 409<!--<h2 id="other-intents">Other Intents</h2> 410 411<p>The following Intents related to In-app Billing may be useful in your 412implemention. </p> --> 413 414<h3 id="http-api">REST API for subscriptions</h3> 415<p>Google Play offers an HTTP-based API that you can use to remotely query the validity of a specific subscription at any time or cancel a subscription. The API is designed to be used from your backend servers as a way of securely managing subscriptions, as well as extending and integrating subscriptions with other services. See <a href="{@docRoot}google/play/billing/v2/billing_subscriptions.html#play-dev-api"> Google Play Android Developer API</a> for more information.</p> 416