If you check the documentation today (20210426) you'll see that now there is no CANCEL notification after an upgrade: CANCEL Indicates that Apple Support canceled the auto-renewable subscription and the customer received a refund as of the timestamp in cancellation_date_ms. Subscription is active; customer upgraded to another SKU: DID_CHANGE_RENEWAL_STATUS, INTERACTIVE_RENEWAL

If you want that one user only have one account in ACME, you can detect that the original_transaction_id is being used by another account, and inform the user that he has another account. If you decide to allow a user have different accounts in ACME, then that shouldn't be a problem because the user is the same with two accounts. If the user is the same, it shouldn't matter what account he used to log in. To share subscription between members of a family, Apple has now Family Sharing: https://developer.apple.com/documentation/appstoreservernotifications/notification_type#3733656

If the user reactivates a subscription, you'll receive a notification with the same original_transaction_id, that you should have store in your database related to the user that make the initial purchase using the app. It the last subscrition happened long time ago, and the user reactivates his subscription from outside the app, I think it is posible that you receive a INITIAL_BUY notification, with a different initial_transaction_id, that you don't have in the database, so you don't know the user that made the purchase. You should tell the user to launch the app, where it should obtain the receipt, the original transaction_id and the user ID, and send it to he server. That way you can add the user ID to the database record that matches the original_transaction_id. You can see videos from wwdc2020, wwdc2019 y wwdc2018 related to server to server notifications: https://developer.apple.com/videos/play/wwdc2020/10661/?time=654 See Resources to find more information

In the transcript of the video https://developer.apple.com/videos/play/wwdc2020/10661/ you can find that after a successfull auto-renew you will receive DIR_RENEW You mention a RENEWED notification, but it doesn't exist (it never existed). The one that existed, and it is deprecated is RENEWAL. But RENEWAL was a very bad name, because it true meaning was "There were failures when Apple tried to collect, but in the end it was able to do so". Now the have a better name: DID_RECOVER. In https://developer.apple.com/documentation/appstoreservernotifications/notification_type#discussion you can see it: RENEWAL (DEPRECATED IN SANDBOX) Indicates a successful automatic renewal of an expired subscription that failed to renew in the past. Check expires_date to determine the next renewal date and time. This notification is deprecated in the sandbox environment, and scheduled for deprecation in production in March 2021. Update your existing code to rely on DID_RECOVER notification type instead.

Can you show an example of the JSON you are receiving? Does it happen in Sandbox or Production?

Hello, PBK I do the decoding passing the receipt from the app to our server, and calling verifyReceipt. And I receive the same original_transaction_id when making purchases from different devices. I think that you'll get a different original_transaction_id when: You make a purchase belonging to a different subscription group, or When more than 180 days have passed since you made the last subscription purchase, so you will not be able to resubscribe to an expired subscription, and you will have to make a new purchase (of which you will receive an INITIAL_BUY notification if you have active server notifications).

Rich, is it possible that INTERACTIVE_RENEWAL is sent when the change in the subscription is to be applied instantly, and that DID_CHANGE_RENEWAL_PREF is sent when the change is to be made at the end of the current subscription? Perhaps these article in RevenueCat.com can be relevant (you'll have to reconstruct the URLs from fragments, that I can't post it in the right way): https:// www. revenuecat.com/blog/ios-subscription-groups-explained https:// www. revenuecat.com/blog/apple-subscription-notifications-are-almost-useless

Hello, ajhank2. In English: Since in server notifications Apple does not send data that allows you to relate a user to the notification received, when you receive a notification of an initial purchase (INITIAL_BUY) you will not know which user it corresponds to. When you receive the INITIAL_BUY notification you should save the record in your database, waiting to be able to relate it later with a user. To obtain that information you would have to ask the user to connect to the app, retrieve the receipt and the original_transaction_id related to that purchase, send it to the backend server along with the user's ID in your system (logged in the app), so that it executes the call to the verifyReceipt URL using the receipt (obtained from the app). In the value returned by verifyReceipt you should have that original_transaction_id (which confirms the validity of the receipt) and on the server you can now link the values of original_transaction_id and the user ID. The next notifications you receive with the renewals will arrive with the original_transaction_id, which you will already have linked in your database with a user, so you have no problem to know who they correspond to. If you let the subscriptions expire, from the app you can resubscribe and the same original_transaction_id that was generated in the first purchase will be used. If you go more than 180 days without renewing any subscription, the next time you buy you will receive another INITIAL_BUY notification, and you will be in the same case again. In our case it is normal that the first purchase is made in the app, so at that moment, when we have the receipt, the original_transaction_id and the user ID, in the call to our backend (API Gateway in AWS), is when we make the data binding, so that the following notifications we have all the data we need. In Spanish: Dado que en las notificaciones de servidor Apple no envía datos que permitan relacionar un usuario con la notificación recibida, cuando recibes una notificación de la una compra inicial (INITIAL_BUY) no sabrás a qué usuario corresponde. Cuando te llegue la notificación INITIAL_BUY deberías guardar el registro en tu base de datos, a la espera de poder relacionarla posteriormente con un usuario. Para obtener esa información tendrías que pedirle al usuario que se conectara a la app, recuperar en ella el receipt y el original_transaction_id relacionado con esa compra, enviarla al servidor de backend junto con el ID del usuario en tu sistema (logado en la app), para que este ejecute la llamada a la URL de verifyReceipt con usando el receipt (obtenido de la app). En el valor devuelto por verifyReceipt deberias tener ese original_transaction_id (lo que confirma la validez del receipt) y en el servidor ya puedes vincular los valores de original_transaction_id y el ID del usuario. Las siguientes notificaciones que te lleguen con las renovaciones llegarán con el original_transaction_id, que ya tendrás vinculado en tu base de datos con un usuario, con lo que no tienes problema para saber a quién corresponden. Si dejas que las suscripciones caduquen, desde la app puedes resuscribirte y se usará el mismo original_transaction_id que se generó en la primera compra. Si estás más de 180 días sin renovar ninguna suscripción, la proxima vez que compres se recibirá otra notificación INITIAL_BUY, y volverás a estar en el mismo caso. En nuestro caso lo normal es que la primera compra se haga en la app, por lo que en ese momento, en el que tenemos el receipt, el original_transaction_id y el ID del usuario, en la llamada a nuestro backend (API Gateway en AWS), es cuando hacemos la vinculación de los datos, para que las siguientes notificaciones tengamos todos los datos que necesitaremos. Kind regards, Oscar

I agree with peter.y. It's being a very frustating development experience... Notifications that you can't test in Sandbox, fields that don't exist in Sandbox, notifications that don't arrive on time,...

This is a fragment of one notification (redacted) I've receive "pending_renewal_info" : [ { "auto_renew_product_id" : "XXXXXXX0001", "auto_renew_status" : "0", "expiration_intent" : "1", "is_in_billing_retry_period" : "0", "original_transaction_id" : "1000000XXXXXXX924", "product_id" : "XXXXXXX0001" }, { "auto_renew_product_id" : "XXXXXXX00000001BR", "auto_renew_status" : "1", "original_transaction_id" : "1000000XXXXXXX939", "product_id" : "XXXXXXX00000001BR" } ], As you can see, it is a numeric value (1 in this case) expresed as a string ("1").

Additional information (such as it appears today 20210405): In https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt/latest_receipt_info it says: Properties cancellation_date string The time when Apple customer support canceled a transaction, in a date-time format similar to the ISO 8601. This field is only present for refunded transactions. cancellation_date_ms string The time when Apple customer support canceled a transaction, or the time when the user upgraded an auto-renewable subscription plan, in UNIX epoch time format, in milliseconds. This field is only present for refunded transactions. Use this time format for processing dates. For more information, see cancellation_date_ms. cancellation_date_pst string The time when Apple customer support canceled a transaction, in the Pacific Time zone. This field is only present for refunded transactions. cancellation_reason string The reason for a refunded transaction. When a customer cancels a transaction, the App Store gives them a refund and provides a value for this key. A value of “1” indicates that the customer canceled their transaction due to an actual or perceived issue within your app. A value of “0” indicates that the transaction was canceled for another reason; for example, if the customer made the purchase accidentally. Possible values: 1, 0 So those fields would be expected only when there was a refund.

The field you should use is original_transaction_id, not transaction_id. That's the value you should use when receiving notifications to search in your database in order to identify the user related to that original_transaction_id. When the use makes is initial purchase from the app, you have to send the user ID and the original_transaction_id to your server, and save that information in the database. When the INITIAL_BUY happens "outside the app", you will not have the information about the user, so you'll have to go to the app to recover the receipt and its original_transaction_id to be able to make the relation between the user ID and the original_transaction_id.

Would you send a request to https://feedbackassistant.apple.com/ to ask them to add modification time in documentation pages, and a changelog when there is a change in behaviour or documentation?

Perhaps this sample code can help you: https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/determining_service_entitlement_on_the_server (This appears linked in one of the URLs below) https:// github.com/paulw11/subscription-monitor Some other links from WWDC2020 with explanations about server-to-server notifications Architecting for subscriptions https:// developer.apple.com/videos/play/wwdc2020/10671 Engineering Subscriptions https:// developer.apple.com/videos/play/wwdc2018/705/ What’s new with in-app purchase https:// developer.apple.com/videos/play/wwdc2020/10661 Note: It seems incredible for me that I can't include links to Apple websites... I've have had to break URLs in order to be able to send this message... You'll have to recreate the original URLs from its fragmentsç Additional ones related to server-to-server notifications: Introducing StoreKit Testing in Xcode https:// developer.apple.com/videos/play/wwdc2020/10659 Subscription Offers Best Practices https:// developer.apple.com/videos/play/wwdc2019/305/ In-App Purchases and Using Server-to-Server Notifications https:// developer.apple.com/videos/play/wwdc2019/302/

You have to get the user id from your app, and transmit it to your backend served (with the receipt you got in the app when the user made the purchase), with the original_transaction_id, to store in your database. Then, when you receive a notification with a original_transaction_id, you can query your database to find out the user related to that notification.