original_purchase_date posterior to purchase_date ?

Hi,


I noticed something kinda odd when performing receipt validation against Apple servers.


This is a part of Apple's response when validating my receipt against the Sandbox server, regarding an auto-renewable IAP, after calling restoreCompletedTransactions() on the SKPaymentQueue (sensitive data edited out) :


{

"quantity": "1",

"product_id": "com.mycompany.myappid.myproductidentifier",

"transaction_id": "100000051***3",

"original_transaction_id": "100000043***2",

"purchase_date": "2018-08-30 19:24:10 Etc/GMT",

"purchase_date_ms": "1535657050000",

"purchase_date_pst": "2018-08-30 12:24:10 America/Los_Angeles",

"original_purchase_date": "2019-03-28 11:04:28 Etc/GMT",

"original_purchase_date_ms": "1553771068000",

"original_purchase_date_pst": "2019-03-28 04:04:28 America/Los_Angeles",

"expires_date": "2018-08-30 19:29:10 Etc/GMT",

"expires_date_ms": "1535657350000",

"expires_date_pst": "2018-08-30 12:29:10 America/Los_Angeles",

"web_order_line_item_id": "100000004***1",

"is_trial_period": "false",

"is_in_intro_offer_period": "false"

},


It was my understanding that, when talking about auto-renewable products, original_purchase_date is the date of the original subscription (should be unique for the first purchase and all the subsequent renewed purchases), and purchase_date is the date of the purchase we're currently checking (could be the same one as original_purchase_date if this is indeed the original transaction, or could be posterior to the original_purchase_date if this is a renew).


In this receipt, I notice that the purchase_date is 2018/08/30, while the original_purchase_date is 2019/03/28 ; did I get it all wrong, or is this some kind of glitch in the Sandbox receipt ?


Thanks for your help.

Answered by in 354856022

This is a bug report against the App Store Server. You can submit such report using the Apple Developer Bug Report web page - <http://bugreport.apple.com>

When creating the bug report, select the Product "Other".

Include the application ID in the bug report and that the issue is for the sandbox environment.

For this issue, include the base64 encoded appStoreReceipt contents as a text file enclosure or directly in the bug report description.

As this appStoreReceipt is for an auto-renewable subscription, please include the app-specific shared secret so that the appStoreReceipt can be manually validated.


You should not see this in the production environment - but if so, it's another bug report but certainly a much higher priority issue.


rich kubota - rkubota@apple.com


developer technical support CoreOS/Hardware/MFI

Accepted Answer

This is a bug report against the App Store Server. You can submit such report using the Apple Developer Bug Report web page - <http://bugreport.apple.com>

When creating the bug report, select the Product "Other".

Include the application ID in the bug report and that the issue is for the sandbox environment.

For this issue, include the base64 encoded appStoreReceipt contents as a text file enclosure or directly in the bug report description.

As this appStoreReceipt is for an auto-renewable subscription, please include the app-specific shared secret so that the appStoreReceipt can be manually validated.


You should not see this in the production environment - but if so, it's another bug report but certainly a much higher priority issue.


rich kubota - rkubota@apple.com


developer technical support CoreOS/Hardware/MFI

Alright Rich,


I just filed a bug as you suggested ; bug ID is 49418465 for future reference.

Sadly I'm not yet able to say if this happens on the production environment as well, but I'll be sure to file another bug report if it turns up that it does.


Thank you !

The sandbox is understandably confused because in the sandbox environment after 5 autorenews the autorenew function is shut off. So it needs to interpret what happened after your last purchase. You made a purchase, you got a receipt and then ----- no autorenews but no subscription cancellation. This confusion does not occur in production.

Oh, I assumed that it would behave as if the user had cancelled auto-renew after 5 renewals.

I find it weird that it's not the case, but what I'm seeing in the receipt makes a little more sense knowing this. As long as this doens't occur in production, everything should be fine though. Thanks a bunch PBK !

This is the answer I've got today (20210621) from Feedback Assistant:

Apple - Jun 21, 2021 at 2:23 PM

Engineering has provided the following information regarding this issue:

In sandbox, such issues can happen if the purchase was made on or before 2018 as transactions created in or before 2018 were deleted. So, the original transaction data was not available and we use the date of the restored transaction as a fallback. This shouldn't happen in production.

Kind regards,

Oscar

original_purchase_date posterior to purchase_date ?
 
 
Q