I have consumables and auto-renewable subscriptions, both of which are user-generated content through admin web panel, so I've created a few of price tiers, with matching "products" in App Store.
I've setup server-to-server notifications for subscription renewal handling, and "initial-buy" endpoint for receipt verification and initial buy, since I have to associate the purchase with my user id, I can't use INITIAL_BUY webhook.
When subscription is initially bought (transaction status = purchased), I call initial buy endpoint which verifies the receipt and unlocks the content for the user. When the subscription is renewed, I extend user's access via DID_RENEW notification. But then when user opens the app, renewal comes in the purchase queue and verify/initial buy endpoint gets called again. I could check for duplicate to avoid it, but then I can't finish the purchase, and it's forever stuck in queue. (my logic is if verify and initial buy backend API call return success, finish transaction and show success screen). I've thought about disabling webhook, but I would like to use it, otherwise I'm not sure if server will process the information in time.
Another issue is with consumables, where I don't know how to reliably associate the ItemId with productId in case the transaction is being processed afterwards. If the user has purchased the item just now, I can handle it, but Apple says the app needs to be able to process the purchase at any moment, so I'm not sure if my solution of using itemId depending on which item the user last clicked "buy" is reliable enough. Does the app really need to be able to process the purchase at any given moment in case of consumables?
I've setup server-to-server notifications for subscription renewal handling, and "initial-buy" endpoint for receipt verification and initial buy, since I have to associate the purchase with my user id, I can't use INITIAL_BUY webhook.
When subscription is initially bought (transaction status = purchased), I call initial buy endpoint which verifies the receipt and unlocks the content for the user. When the subscription is renewed, I extend user's access via DID_RENEW notification. But then when user opens the app, renewal comes in the purchase queue and verify/initial buy endpoint gets called again. I could check for duplicate to avoid it, but then I can't finish the purchase, and it's forever stuck in queue. (my logic is if verify and initial buy backend API call return success, finish transaction and show success screen). I've thought about disabling webhook, but I would like to use it, otherwise I'm not sure if server will process the information in time.
Another issue is with consumables, where I don't know how to reliably associate the ItemId with productId in case the transaction is being processed afterwards. If the user has purchased the item just now, I can handle it, but Apple says the app needs to be able to process the purchase at any moment, so I'm not sure if my solution of using itemId depending on which item the user last clicked "buy" is reliable enough. Does the app really need to be able to process the purchase at any given moment in case of consumables?