Testing Status Update Notifications

How do we test status update notifications in the sandbox environment? We can make the inital buy, but are having trouble simulating the upgrade/downgrade event between two IAP products which are in the same group. Sine this is using a sandbox user, we can't manage our subscriptions so we don't know how to simulate/trigger this notification.


Any help would be greatly appreciated.

Replies

It appears that you relying on server-to-server notifications to keep abreast as to the status of the auto-renewing subscription In-App Purchase item offered by your application. You should review Tech Note 2413 - "In-App Purchase FAQ"


https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_


My server process rarely receives RENEWAL notices when the auto-renewing subscription renews.


Your application process implements support for the server-to-server notification service for auto-renewing subscriptions and expects to receive the RENEWAL status update notification when a renewal occurs. The description for the RENEWAL notification type in Table 6-4 Status Update Notification Types needs clarification. The description states "Automatic renewal was successful for an expired subscription. Check Subscription Expiration Date to determine the next renewal date and time.


The App Store attempts to charge the user account 24 hours before an auto-renewing subscription expires. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into the expired state. However, in the few cases that iTunes is unable to renew the subscription (generally there was a connection problem with the credit card server) and the auto-renewing subscription is not renewed before the expiration_date passes, the auto-renewing subscription is technically considered expired. iTunes may continue to attempt to renew the subscription. If iTunes is successful, then the RENEWAL event is sent. For this reason, the advice is presented - Check Subscription Expiration Date to determine the next renewal date and time.


For a normal renewal where the user account is successfully charged before the subscription expires, validate the appStoreReceipt. Check the contents of the latest_receipt_info field to verify that there is an auto-renewing subscription in-app purchase item where the expires-date is later than the current date.


If you are expecting a RENEWAL notification whenever the auto-renewing subscription renews, this would be an enhancement request to be submitted for the App Store server engineers to implement. You can submit such enhancement request using the Apple Developer Bug Report web page - http://bugreport.apple.com.


As to your comment about detecting - update notifications, the update purchase will result in a call to the application's updatedTransactions delegate method. The app can then notify your server that the update occurred. Interestingly, when a downgrade attempt occurs, the following happens

1. The user is notified that the change to the downgraded auto-renewing subscription will occur when the current subscription expires.

2. The app will see the updatedTransactions delegate method called with the SKPaymentTransactionStateFailed response.

3. There should be the DID_CHANGE_RENEWAL_PREF server-to-server notification.


The reason for the failure event - the purchase attempt was not successful - that is the user account was not charged at that point in time. The user account will be charged later. The app can verify with the validated appStoreReceipt that there is currently an active auto-renewing subscription, which was active before and is still active.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Thank you for the information regarding the renewal notification.


In the documentaion:

https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html


I'm looking at Table 6-4. The DID_CHANGE_RENEWAL_PREF is the notificaiton type I'm looking to test. I'd want to know when a user changes their current plan (Upgrades/downgrades between multiple products in a subscription group). How do we generate this notification type in the sandbox environment?


In the production envionment, I would purchase one of the two subscriptions in a group. Then via subscription management, I can choose to cancel it or upgrade to another subscription in the same group. How do I simultate this in the sandbox environment?

Based on the description of the DID_CHANGE_RENEWAL_PREF notification - Customer changed the plan that takes affect at the next subscription renewal. Current active plan is not affected. This tells me that such notification should be generated when the user enters iTunes and changes their subscription either upgrade or downgrade. Unfortunately, this situation cannot be generated in the sandbox as a test user account (or a TestFlight user) has no means to access sandbox subscriptions. This would be an enhancement request for the App Store server folks to generate.


One other way that I suspect that this notification can be generated in the sandbox is to attempt a downgrade of an auto-renewing subscription. Per the In-App Purchase Programming Guide - "Working with Subscriptions" section. the description for downgrades - Downgrades of any duration or cross-grades with different durations go into effect at the next renewal date.


When a downgrade is attempted, the user is presented with an alert that the change in subscription plan will go into effect at the end of the current subscription. Try this and see if a notification is generated - otherwise, please submit a bug report.


rich kubota - rkubota@apple.com


developer technical support CoreOS/Hardware/MFI

Hi,

How do I generate a downgrade in the sanbox environment? In sandbox, I am not able to manage my subscriptions via the settings.


Thanks,

Suhale

I think the answer is that there is no way to test. Which is a nightmare for everyone involved. Please, Apple.... get this together.