I have two apps with bundle IDs 'com.my.ios.stage' and 'com.my.tvos.stage'. (Not a real ID) The subscription groups are test.com.ios.subs and test.com.tvos.subs respectively. When I create a subscription for the test.com.ios.subs group on ios, the receipt is generated well and the app store notification is also working well and notifications are coming. The subscription created with test.com.tvos.subs does not receive any notifications. However, when I create a subscription for the test.com.tvos.subs group on tvos, the receipt is generated well, but the notification is not coming. For both subscriptions, if I parse the receipt and look up transactionHistory with transactionId, there is information about the previously purchased subscription. I tried to get the notification history of each app with get_notification_history. In com.my.ios.stage, I can see all the subscription information, including the notification I created with request_test_notification. In com.my.tvos.stage, I only see the notification created with request_test_notification. I'm testing in a sandbox. What is the issue?

Our service has an IOS and Android app and a backend server. I have a question about handling refunds for simultaneous payments on Android and IOS. Is there any way to cancel and refund the IOS subscription payment in the backend when Google is paid first and IOS is paid almost simultaneously? For Android, unlike IOS IAP, the backend server can confirm the purchase with a purchase confirmation (ack), so even if IOS is paid first at almost the same time, it is possible to cancel it by checking the payment data in the backend and not sending an ack to Google's server if the IOS payment is already made.

We are using Apple Notification V2 and supporting only one subscription service per user (e.g., Netflix with Basic, Premium plans). In Notification V1, we could fetch the latest subscription information using the /verifyReceipt API. However, the documentation for Notification V2 suggests using SignedDataVerifier to decode the data locally. This raises a concern that the data received via notification might not always be up-to-date. For example, if a user cancels a subscription but the server fails to process the notification for some reason, and later the user upgrades and resumes the subscription, the new notification succeeds. In this scenario, the previously failed cancellation notification will be resent after some time. How should the backend server handle this? Should we always use APIs like get all subscription statuses to fetch the latest data instead of solely relying on the decoded data from each notification?