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.

We had our subscription status url set up and had been receiving server-to-server notifications in sandbox for months until 3/19 JPT. Since then they just stopped coming in. Seems like a problem on Apple's end. Anyone else experiencing similar issues?

Seems like there were some changes made to the receipt validation's sandbox environment behaviors since around a week ago.1) when a subscription product is purchased, I get the prompt asking whether I want to turn off automatic renewal (new) but my dialogue choice is irrelevant because in the receipt validation response the auto_renew_status is always 12) the subscription product used to get automatically renewed 5 times before it goes into billing retry period, but now it does not get renewed even when auto_renew_status = 1 before the expires_date.3) the subscription now enters its grace_period whereas it didn't before4) auto_renew_status retains its value even after the subscription expires. It used to become 0 before. These seem like merely behaviorial changes in sandbox and may not reflect changes in the production environment. However I would really like to know if there were official documentations on the changes, as things still seem a bit unstable (per point 1 and 2) and I don't want to make assumptions on auto_renew_status based on its sandbox behavior.