Post not yet marked as solved
Apple seems to have fixed this as we mostly stopped getting the error 5 hours ago.
Post not yet marked as solved
We've been getting 500000 from one of our apps when calling the subscription status GET API in the sandbox environment since about 10 hours ago.
GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/subscriptions/{originalTransactionId}
Production environment seems to be unaffected at the moment. Nonetheless seems like a problem on Apple's end?
Post not yet marked as solved
Thanks. I've filed a ticket FB11989240 with a sample from our sandbox environment.
After a bit more testing I'm going to answer myself on a couple of things.
setting extendByDays to 90 days seems to extend the subscription by 38 minutes in Sandbox.
resetting introductory offer eligibility through Settings also seems to reset the twice a year limitation.
It would be great if I can get a little more detail on when "success = false".
Thanks for the reply! Now I have a few more questions.
Is it possible for you to briefly explain or point me in the right direction how sandbox scaling works in this instance?
Is there a way to reset the twice a year limitation in sandbox, like the ability to reset introductory offer eligibility?
when I exceed the twice a year limitation and call the API again, is it correct to assume that I will get a 200 response with the body of a previous extension attempt? since from my observation "success" always seems to be true in the body.
Post not yet marked as solved
Thanks, just sent in a bug report.
It's been two weeks since I submitted this to the feedback assistant but there's still no response from Apple.
Post not yet marked as solved
Here is a sample of the notification exhibiting this bug, but like farias said there is no way to know which subscriptions are associated.
{
"notification_type": "DID_RENEW",
"password": "********************************",
"environment": "PROD",
"auto_renew_product_id": "***",
"auto_renew_status": "true",
"bid": "***",
"bvrs": "***"
}
We have a batch that calls verifyReceipt to ensure subscription validity so this does not present a huge problem for us but I'm sure we'd all like t see this fixed.
Post not yet marked as solved
Thanks, just sent in a bug report.
FYI it is still happening in our production environment.
is it possible to test this in the sandbox environment?
Post not yet marked as solved
Also a point of concern:
https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt
[unified_receipt.Latest_receipt_info]
An array that contains the latest 100 in-app purchase transactions of the decoded value in latest_receipt. This array excludes transactions for consumable products your app has marked as finished.
I'd assume that refunded transactions for consumable products ARE included in latestreceiptinfo but that sort of contradicts with the above description. And this is why I'd like to be able to test this in sandbox.
