With regards to the interface file SKPaymentTransaction.h and the declaration in the interface that the transactionReceipt field is deprecated, the interface file is the official declaration as to the state of this field. It's my understanding that the transactionReceipt field is still active per the iTunes Store Server engineering group, but until the interface file is changed, the transactionReceipt field is deprecated. I’m told by the iTunes Store Server engineering group that the store continues to return the transactionReceipt for a successful transaction.
While the transactionReceipt field is marked as deprecated, that doesn't mean that the latest_receipt and the latest_receipt_info JSON fields in a validated applicationReceipt (as referenced by [NSBundle mainBundle] appStoreReceiptURL]) are also deprecated. The iTunes Store Server engineers indicate that these fields are valid portions of the validated applicationReceipt.
The value of the latest_receipt_info - once this information is captured for an auto-renewing subscription in-app purchase item, the latest_receipt_info can be used independently to view the renewal status of the auto-renewing subscription item (and items in the group). I refer you to the statement in the “Receipt Validation Programming Guide” <https:/
“The values of the latest_receipt and latest_receipt_info keys are useful when checking whether an auto-renewable subscription is currently active. By providing any transaction receipt for the subscription and checking these values, you can get information about the currently-active subscription period. If the receipt being validated is for the latest renewal, the value for latest_receipt is the same as receipt-data (in the request) and the value for latest_receipt_info is the same as receipt.”
The above statement is from the iTunes Store Server engineering team and explains that once the latest_receipt_info field has been captured, that field is base64 encoded and can be resent to the appropriate verifyReceipt server. The JSON response can be parsed and will provide the latest information about the auto-renewing subscription item. The result can contain multiple items, and for this reason. As such the status result 21006 does not apply. This is because there can be multiple items in the response and the expired status may not apply to all items. When the status of 0 is returned, the receipt was successfully validated and the app (or server process) must process the returned results individually.
In my testing, with a subscription group, I found that by capturing the latest_receipt_field from the initial purchase, I could then validate the latest_info_results contents and watch as the auto-renewing subscription item renewed. If I switch to another auto-renewing subscription item in the group, then validated the same original receipt, the change to the different auto-renewing subscription group item was recorded. You can perform this test yourself in the sandbox to see the results.
I kept the contents of the first applicationReceipt from which I used to capture the initial latest_receipt_info contents. In this initial JSON result, there was the single item in the in_app array. Later I validated the same applicationRecept after the renewal occurred (in the sandbox) and found that the in_app array still had the one auto-renewing subscription item, but the latest_receipt now contained a second item with the auto-renewing subscription renewal. As the subscription renewed, I validated the exact same applicationReceipt - with similar results, the in_app array maintained the one item, but the latest_results fields showed the renewals.
One additional note, a user has the option to terminate an auto-renewing subscription item in their iTunes account. The server process can only detect an expired auto-renewing subscription when there is no active auto-renewing subscription item in the JSON results (in_app array or in the latest_receipt_info). In addition, the user can restart an expired subscription in their iTunes account. By validating the latest_receipt, a server process can detect that the expired auto-renewing subscription item has been restarted.
This mechanism makes it possible for a server process to track the auto-renewing subscription renewal process rather than do so on the app. The one thing that the server renewal process cannot track is a cancellation. By cancellation, I mean when the user with an active auto-renewing subscription contacts Apple Care to complain that there was some problem and requests a refund. If the refund is approved, the subscription is cancelled. The iTunes Store Server engineers have proposed a means to handle this in the latest_receipt, and I’ve asked the team to document the process. I expect that the Receipt Validation Program Guide will be updated when such change is finalized. In the meantime, the only official means that I’m aware of to detect a cancelled auto-renewing subscription is to have the application refresh the applicationReceipt, then validate the applicationReceipt. In such case, there will be a “recent” auto-renewing subscription item where the cancellation_date field is set with the date of cancellation.
rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI
