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

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.

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

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

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

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, 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).

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,...

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.

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").

I don't know the actual reason, because the documentation about notifications is incomplete, confusing and changing... I don't know if the cancellation_date appears when CANCEL means a refund (of a auto-renewing subscription). But this is just an idea, in case this gives you a clue. In Handling Subscriptions Billing it - https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/handling_subscriptions_billing#3221919 it says: Detect a Refund Users pay for a subscription when they purchase it, and they can receive a refund by contacting Apple customer service. For example, if the user accidentally buys the wrong product and requests a refund, customer support can cancel the subscription and issue a full or partial refund. Customers may cancel a subscription in the middle of a subscription period, but the subscription remains paid through the end of the same period. Additionally, users may also receive a refund when they upgrade their subscription to another subscription product at a higher level in the same subscription group. To identify whether a subscription has been refunded, look for the cancellation_date field in the receipt. The App Store notifies your server of refunds with a status update notification of type CANCEL, at which point you can handle the refund. For example, if the user upgraded the subscription, immediately unlock service for the higher level subscription product purchased. But I'm not sure of anything about notifications... They are a actual mess... I've found several articles writing about the uselessness of server-to-server notifications (recreate the URL from this fragments, deleting spaces and End-Of-Line chars, that I can't post URLs): https://www. revenuecat.com/blog/apple-subscription-notifications-are-almost-useless https:// blog.apphud.com/subscriptions-notifications/

At the bottom of https://developer.apple.com/documentation/appstoreservernotifications there is a link "Your Server. Specify your secure server’s URL in App Store Connect" that points to https://developer.apple.com/documentation/appstoreservernotifications/your_server In the Discussion section, there is a linked text: See Enter a URL for App Store Server Notifications for instructions. that point to https://help.apple.com/app-store-connect/#/dev0067a330b where you can see where you should enter the URL. The image is: https://help.apple.com/app-store-connect/en.lproj/GlobalArt/Subscription_Status_URL.png Perhaps you should browse the previous sections, in the left pane.

You can see the structure of unified_receipt in: https://developer.apple.com/documentation/appstoreservernotifications/unified_receipt

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/