When I test my iOS subscription purchases in the sandbox environment, sometimes the original_transaction_id returned by receipt verification changes (gets incremented by 1 to be precise) when I receive the corresponding server-to-server notification. Very rarely this would happen in the production environment as well but lately I notice this more often in sandbox. Anybody else experiencing this?

I'm testing this App Store Server API in the sandbox environment and it seems like this API cannot be properly tested there. https://developer.apple.com/documentation/appstoreserverapi/extend_a_subscription_renewal_date I can only call this API on an active subscription, but the effectiveDate in ExtendRenewalDateResponse is the same value as the subscription's original expiry date and is not extended at all by the extendByDays I specified in the API request. Also the subscription doesn't renew after it expires, so even if the call to the subscription extension API appeared to have succeeded it has no actual effect. I suppose this is not the intended behavior and expect that the production environment to behave differently. Is the expiresDate in the current subscription supposed to be extended after this API call? Or would it remain the same and the extended part of the subscription become a separate transaction after expiresDate?

https://developer.apple.com/documentation/appstoreserverapi/send_consumption_information If the customer provided consent, respond by calling this API and sending the consumption data in the ConsumptionRequest to the App Store. If not, respond by calling this API and setting the customerConsented value to false in the ConsumptionRequest; don't send any other information. Since our server would be receiving CONSUMPTION_REQUEST server notifications and will be the one calling the Consumption API, how do we know if the user has provided consent? That info doesn't seem to be in the server notification or anywhere else.

We just started receiving server notifications a day ago and detected a number of them missing the unified_receipt field. They're all subscription related notifications and without that field it is not possible to track down which transaction the notification is related to. Is this a bug?

Even though we can finally manage our sandbox subscriptions through settings on iOS14, cancelled subscriptions there are only treated as such and not as a refunded subscription. I would like to know if there's a way to refund a sandbox purchase (consumables or subscriptions) and have a REFUND notification sent so we can test such behaviors.

through their account settings -> subscriptions. Logical answer would be yes but since this is not something that can be tested on a sandbox account and it's not easy to reproduce in production. Would like a quick answer here.