Testing subscriptions in sandbox

Ivan,

The following is some clarifications to the Status Update Notification Types

Status Update Notification Types Clarification

<https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html>

The one notification which your server should always receive is when the user purchases the auto-renewing subscription the first time.

Let me clarify the other notifications types

CANCEL - Subscription was canceled by Apple customer support. Check Cancellation Date to know the date and time when the subscription was canceled.

Clarification - the term cancel is the specific case where the user contact Apple Care, requests a refund for the auto-renewing subscription In-App Purchase, is granted the refund, and the auto-renewing subscription has the cancellation_date set. This event is not the same as when the user enters their iTunes account - Subscription section, and indicates that they choose not to allow an existing auto-renewing subscription to renew. There is no notification type for this event. I call this the “EXPIRE” event - there is no server-to-server notification when the user makes this choice. There is no support at present to simulate this event in the sandbox environment.

The only way for an application to detect that the auto-renewing subscription has simply expired is for the app process to validate the appStoreReceipt and to find that there is no longer an iAP item showing the expires_date greater than todays date. The process should also check for the presence of the is_in_billing_retry_period field in the most recent entry to determine whether the App Store is attempting to renew the auto-renewing subscription.

RENEWAL - Automatic renewal was successful for an expired subscription. Check Subscription Expiration Date to determine the next renewal date and time.

Clarification - in general, iTunes will attempt to charge the user account a day before an auto-renewing subscription is scheduled to expire. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into an 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”. However, iTunes will still continue to attempt to renew the subscription. It 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.” There is no support at present to simulate this event in the sandbox environment.

For a normal renewal which is successful before the subscription actually expires, validate the appStoreReceipt and check the contents of the latest_receipt_info to verify that there is an auto-renewing subscription in-app purchase item where the expires-date is later than the current date.

INTERACTIVE_RENEWAL - Customer renewed a subscription interactively after it lapsed, either by using your app’s interface or on the App Store in account settings. Service is made available immediately.

Clarification - If a customer purchases an auto-renewing subscription then after some period of time, allows the subscription to expire, that is their choice. However later on, iTunes provides the user the option to restart the auto-renewing subscription in their account -> Subscription page. Alternatively, the user could purchase the AUTO-RENEWING SUBSCRIPTION in the app. When either event occurs, iTunes sends this notification.

DID_CHANGE_RENEWAL_PREFERENCE - Customer changed the plan that takes affect at the next subscription renewal. Current active plan is not affected.

Clarification - If your app offers multiple items in an auto-renewing subscription group, then if the user has purchased a higher level item and attempts to switch to a lower grade auto-renewing subscription item (this is considered an auto-renewing subscription downgrade), then this notification is sent to your process. The higher level auto-renewing subscription will continue until the expiration_date - at which time the downgrade auto-renewing subscription will be put into effect.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Rich,

Thank you for the helpful answer!

Could you please also clarify the situation with upgrades?

Regarding to the documentation downgrades of any duration or cross-grades with different durations go into effect at the next renewal date. But there is no word for upgrade.

Do you happen to know if the upgrade goes into effect right away?

I believe they go into effect immediately. I do not understand how the user is appropriately billed for the difference.

Thanks for the detailed description, @rkubota. I have a best practices question I'd like to run by you based on this paragraph of your response:

"For a normal renewal which is successful before the subscription actually expires, validate the appStoreReceipt and check the contents of the latest_receipt_info to verify that there is an auto-renewing subscription in-app purchase item where the expires-date is later than the current date."

In this normal renewal case, where is my server getting the receipt data to validate? Should I save the initial receipt data my app sends the server? My current implementation stores the original_transaction_id to link to the user account, but doesn't save the receipt data for periodic expiration checking. It sounds like that is the preferred method.

Thanks for the help!