Skip to content

Instantly share code, notes, and snippets.

@matthiasplappert
Created April 26, 2011 13:40
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save matthiasplappert/942278 to your computer and use it in GitHub Desktop.
Save matthiasplappert/942278 to your computer and use it in GitHub Desktop.

iOS In App Purchases

Apple summarizes the whole flow of server-side In App Purchases in this graph. It’s a very good starting point to get the overall idea what it necessary.

flow

Overview of Required APIs

  • GET available product identifiers
  • POST the iTunes transaction receipt for validation and retrieve redeem code as response

That’s pretty much it.

List of Available Product Identifiers

A set of available product identifiers. Product identifiers are strings and must not be human-readable. The API should only return product identifiers that have been added to iTunes Connect and have been approved by Apple. I’d suggest something like com.linebreak.CloudAppPro.1month.

Transaction Validation

Once the iOS app completes the iTunes Store transaction, we need to validate it. The app therefore sends the transaction receipt to CloudApp server. The receipt is binary data. To validate it, you need to send a POST request to https://buy.itunes.apple.com/verifyReceipt. The body of the request must be the following JSON:

{
    "receipt-data" : "(actual receipt bytes here)"
}

The iTunes Store will always respond with the following JSON body:

{
    "status" : 0,
    "receipt" : { ... }
}

If status equals 0, the receipt is considered valid. If status is anything else than 0, the receipt is considered invalid. The HTTP status is not documented, but I assume that it is always 200, even if the receipt is invalid. The iTunes Store further decodes the binary receipt data and adds the following values to the receipt JSON object:

  • quantity: The number of items purchased
  • product_id: The product identifier of the item that was purchased
  • transaction_id: The transaction identifier of the item that was purchased
  • purchase_date: The date and time this transaction occurred
  • original_transaction_id: For a transaction that restores a previous transaction, this holds the original transaction identifier
  • original_purchase_date: For a transaction that restores a previous transaction, this holds the original purchase date
  • app_item_id: A string that the App Store uses to uniquely identify the iOS application that created the payment transaction. If your server supports multiple iOS applications, you can use this value to differentiate between them. Applications that are executing in the sandbox do not yet have an app-item-id assigned to them, so this key is missing from receipts created by the sandbox.
  • version_external_identifier: An arbitrary number that uniquely identifies a revision of your application. This key is missing in receipts created by the sandbox.
  • bid: The bundle identifier for the iOS application
  • bvrs: A version number for the iOS application

The server can use the receipt information to generate a redeem code for the correct period. If the receipt validation has been successful, the server should then respond with the respective redeem code. If the validation did fail, it should return an API error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment