We have a pretty simple setup:
- iOS 14 as min target
- only auto-renewable subscriptions
- Apple S2S integration
Here is, in short, our flow:
APP: We register a PaymentQueue observer early in the application lifecycle and whenever a newly purchased transaction is received, we send the receipt to the backend for validation. This happens regardless of whether the purchase was user-initiated (i.e. for an actual purchase) or not (i.e. autorenewal).
BACKEND: The backend receives the receipt, validates it against verifyReceipt Apple's endpoint, and stores relevant information into the database. This information gets sent back to the app over time in order to let it figure out whether the user is subscribed, and block relevant content if he is not.
Also, we continue poll Apple's endpoint over time as suggested in the well-known WWDC 2018 session.
S2S SERVICE: whenever we receive a notification from Apple, we take the latest receipt base64 data, validate it against verifyReceipt endpoint, and then we use the response to figure out the latest user status and update relevant fields in our backend, including locking/unlocking paid content. This is done differently depending on the notification type, but I don't think it's relevant here.
All that said, I can't figure out the use case for the in-app Restore Purchases process. Do we really need it?
Thanks.
To the note on Restore Purchases, this is a App Review requirement and does allow customers a consistent and safe way to force an app to check their current status and purchases. Please see https://developer.apple.com/app-store/review/guidelines/#in-app-purchase