When transaction ID is changing in iOS7 app receipt?

Question

For iOS 6.1 or earlier, in-app purchase transaction ID received after purchase or restore is unique each time and original transaction id never change, even after restore. However, for iOS7, transaction id and original transaction id is always same! I even tried to refresh receipt, delete app from device and put it back again. Both fields are always same. Does anyone know in which cases transaction id will change? My server logic was relying on unique transaction ID from receipt itself, which currently doesn't work in case of iOS7. Following is app receipt decrypted by Apple server. Same result if I decrypt it locally. ``` { environment = Sandbox; receipt = { "adam_id" = 0; "application_version" = "1.0"; "bundle_id" = "com.###"; "download_id" = 0; "in_app" = ( { "is_trial_period" = false; "original_purchase_date" = "2014-02-18 14:23:40 Etc/GMT"; "original_purchase_date_ms" = 1392733420000; "original_purchase_date_pst" = "2014-02-18 06:23:40 America/Los_Angeles"; "original_transaction_…

Accepted Answer

Transaction dates are updated correctly

We can make use of the observation that the transaction dates are updated correctly (even in the Sanbox environment and surely in Production):

```
"in_app":[{"quantity":"1", "product_id":"###",
    "transaction_id":"1000000122762089",
    "original_transaction_id":"1000000122762089",
    "purchase_date":"2014-09-07 16:15:13 Etc/GMT",
    "purchase_date_ms": "1410106513000",
    "purchase_date_pst":"2014-09-07 09:15:13 America/Los_Angeles",
    "original_purchase_date":"2014-09-07 05:35:16 Etc/GMT",
    "original_purchase_date_ms":"1410068116000",
    "original_purchase_date_pst":"2014-09-06 22:35:16 America/Los_Angeles",
    "is_trial_period":"false"}]
```

You can see that `purchase_date_ms` and `original_purchase_date_ms` differ.

Therefore: enforce uniqueness of the combination of transcation ID and date

Not only store the transaction ID but also the purchase date (not original purchase date) in your server database. The combination of those two values will not exist in your database for a legitimate restore transaction, but will collide with an existing record if the receipt is a replay.

Note that we are looking a response from the validation server, which means that clients won't be able to vary the date, just as they aren't able to vary the transaction ID without breaking the validity of the receipt.

When transaction ID is changing in iOS7 app receipt?

Solution

Problem