Thanks for the comment, the date in the question is supposed to be the date of the removal, not deprecation, I will update my question!

We are also implementing in-app purchases in my team. As far as we've tested notifications can only be triggered by the mobile application (e.g. buying a product) or the apple store (e.g. change the renewal status of a subscription). "How can I test different types of notifications to make sure the app-store server is sending the kind of data I would expect based on the notification type?" As far as we've known you can only test this simulating user behavior. I would advise using the sandbox environment while testing. "There are also some concerns about the reliability of these notifications at present?" I don't think there is a concern about the reliability of these notifications, but apple does retry when your server does not respond with success (HTTP 200 OK). I would not suggest running a background job to poll subscription status, I think you should rely on subscriptions and keep the receipt of the purchases in case of a catastrophic event. But, daily checking for the status of subscriptions was a strategy in the past, before notifications.

I don't think you're able to get the price of a transaction via apple notification or even when validating a receipt. But you do know the product_id via notifications, so you can just look up the price of the product. For old transactions with products that have changed price I do not know how you would be able to get this data.

After many tests we dicovered that if the production URL is different than the sandbox URL, you must use V2 notifications. If both of the URLs are equal, then you can choose to use V1 instead. We were not able to find such rule in the documentation and the App Store Connect interface allows this behaviour as a working scenario, which is not. I believe this should be on the documentation and the interface should raise an error when trying to use V1 notification with differents URLs.