title: IllegalStateException when using Curl to verify App Store receipt?
body: <p>I have an in-app purchase for which I want to verify the store receipt. I'd like to verify this from a random machine on the Internet by using Apple's itunes API. The receipt is stored in Parse after the transaction is completed. I'm following the guide on the <a href="http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html" rel="noreferrer">Apple developer website</a>. First I get the transaction from Parse:</p>
  
  <pre><code>curl -X GET \
    -H "X-Parse-Application-Id: [...]" \
    -H "X-Parse-REST-API-Key: [...]" \
    https://api.parse.com/1/classes/Transactions/123456789
  </code></pre>
  
  <p>which looks like:</p>
  
  <pre><code>{
      "transactionReceipt":{"__type":"Bytes","base64":"asdfqwertyASDFQWERTY="},
      "transactionType":"Purchased",
      "transactionIdentifier":"[...]",
      "transactionDate":{"__type":"Date","iso":"2012-09-10T06:58:44.071Z"},
      "createdAt":"2012-09-10T06:58:37.234Z",
      "updatedAt":"2012-09-10T06:58:37.234Z",
      "objectId":"HyPWJBlWzt"
   }
  </code></pre>
  
  <p>I then take the base64 value inside transactionReceipt and curl it against the Apple endpoint to get the receipt:</p>
  
  <pre><code>curl -H "Accept: application/json" \
       -H "Content-Type: application/json" \ 
       -X POST 
       -d '{"receipt-data":"asdfqwertyASDFQWERTY="}' \
       https://buy.itunes.apple.com/verifyReceipt
  </code></pre>
  
  <p>And all I get back is a not tremendously helpful:</p>
  
  <pre><code>{"status":21002, "exception":"java.lang.IllegalStateException"}
  </code></pre>
  
  <p>which I believe corresponds to a "The data in the receipt-data property was malformed.". Getting curl to dump the entire operation with --trace-ascii didn't reveal anything I thought was relevant, I'm sure the issue is not with the connection itself.</p>
  
  <p>Slightly stumped here. It does look like the transaction was found on their end (tweaking a few bytes in the receipt-data throws a java.lang.IllegalArgumentException), so I'm guessing it's got something to do with the transaction itself. Has anybody seen this before?</p>
  
  <p>Thanks!</p>