Hi there,
We are retro-fitting recurring subscriptions into our system and would like some validation of our approach. We've done a bit of sleuthing around the docs and forums and have not found a solution close to ours.
There are some questions that have arisen regarding this approach, primarily due to the inability to find the appropriate documentation.
2. We would like verification that the App Server Notification with a notificationtype == CANCEL or REFUND is sent at the exact moment a subscription is no longer being paid for versus having to poll Apple on a regular basis to verify whether a subscription is still valid.
3. Is there a way to send an internal transaction identifier to Apple at the time a subscription is purchased and have this same identifier quoted back to us at the time of CANCEL or INITIALBUY?
4. Within the receipt verification step, is there an attribute that is returned that will identify that the subscription is no longer valid? Is this attribute called "expiration_intent"?
5. If we verify the receipt in this way, what is preventing the receipt data from being replayed by a different user by the same user after the initial subscription has lapsed? Will the verification endpoint return the current state of the subscription?
I realize these are a lot of questions and I apologize if there is documentation out there which addresses them which I have not been able to find.
Any help would be greatly appreciated.
We are retro-fitting recurring subscriptions into our system and would like some validation of our approach. We've done a bit of sleuthing around the docs and forums and have not found a solution close to ours.
Overview
Initial purchase
Since we need to associate an in-app product with a specific user, we have chosen to send the receipt to our server for verification. This way, we will be able to extract the user information through the authenticated call it makes. Once we have this, we will verify the receipt and if successful, grant the user access to the subscription they purchased. We will also store the TransactionId retrieved from the receipt.Subscription End
We are relying on the App Store Server notification to send us a webhook call at the exact moment a subscription is no longer valid (notificationtype == CANCEL??). Using the autorenewproductid and originaltransactionid contained within the notification payload, we will find and disassociate the subscription from the user.There are some questions that have arisen regarding this approach, primarily due to the inability to find the appropriate documentation.
Questions
1. We have a Staging and Production environment and would like to verify that the App Store Notifications are being processed correctly before reaching Production. How do we configure the App Store Notifications to send notifications to the correct environment depending on whether the subscription was purchased using a TestFlight build of the app vs a Release version of the app?2. We would like verification that the App Server Notification with a notificationtype == CANCEL or REFUND is sent at the exact moment a subscription is no longer being paid for versus having to poll Apple on a regular basis to verify whether a subscription is still valid.
3. Is there a way to send an internal transaction identifier to Apple at the time a subscription is purchased and have this same identifier quoted back to us at the time of CANCEL or INITIALBUY?
4. Within the receipt verification step, is there an attribute that is returned that will identify that the subscription is no longer valid? Is this attribute called "expiration_intent"?
5. If we verify the receipt in this way, what is preventing the receipt data from being replayed by a different user by the same user after the initial subscription has lapsed? Will the verification endpoint return the current state of the subscription?
I realize these are a lot of questions and I apologize if there is documentation out there which addresses them which I have not been able to find.
Any help would be greatly appreciated.
