Manage Subscriptions URL for Sandbox Testing

I'm building an iOS app with auto-renewable subscriptions. I am generally successful with purchasing, restoration (receipt verification) etc. However, I can never get the hand-off to the Manage Subscriptions screen to work. I'm testing on my device.


Here are the URLs I've tried, as I've seen variations posted in other discussions and Q&A sites


  1. https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions
  2. itms-apps://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions
  3. https://sandbox.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions


The first is what is commonly published, although I've seen mention that the third is unofficial, but the way to get things to work during testing.


In all cases, I authenticate with my sandbox account and this same sandbox account is logged into the App Store via Settings.


My experience:


1. https://buy.itunes.apple.com...

Takes me to the right screen in the Settings app, but indicates there are no subscriptions; even though I authenticated with my sandbox account and the sandbox account is logged into the App Store via Settings.


2. itms-apps://buy.itunes.apple.com...

Works, but is no different than Option 1.


3. https://sandbox.itunes.apple.com...

Endless re-directs asking me to authenticate ad-nauseum.


I realize these services go up and down more often for the sandbox.


Has anyone used this successfully in August 2015 for an iOS8 app?

I have the same question.

In app purchase applications which offer multiple auto-renewing periods for their products should hand-off the user to the

https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions

URL for the user to manage the subscription process. This URL will only work for production accounts to display existing auto-renewing subscriptions for management. In the sandbox, one can only use a test account to trigger the display of the settings screen, however the sandbox environment handles auto-renewing subscriptions in an automated fashion - that is subscription periods are shorted and renew only 5 times and not controlled through the subscription management screen. The fact that the App Store setting screen appears in the sandbox environment means that when the app moves to the production environment and a production user account uses this option, the user will be provided the option to manage their production subscriptions.


If you would like to see this support provided in the sandbox environment, I suggest that you submit an enhancement request using the Apple Developer Bug Report web page - https://bugreport.apple.com


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Rich,

Thank you for the response.


I realized today that I was thinking about this all wrong and I can see why its not as necessary to be able to manage subscriptions. I was thinking that the 'Cancellation Date' field would reflect when a user cancel's (or really just opts out of auto-renewing) their subscription. But I was mistaken this field is only for the times when a user contacts Apple Support and requests to cancel early and receive some sort of a refund, and this is not something that is managed directly by a user.


Thanks again!

Isn't that "exires_date" teh subscriuption expiration date?

corretion...."expires_date"

i am having a very had time implementing auto renewal in app purchase in my app.... you have succesfully done so. could i buy your code or could you hare it with me please

If you are willing to forego receipt verification an auto-renewable is identical to a non-consumable except you extract the expiresDate in updatedTransactions and store that value.

Manage Subscriptions URL for Sandbox Testing
 
 
Q