Post marked as solved
Post marked as solved with 2 replies, 544 views
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.