Replying to @Louna and OP's post.
What I understood
The description is correct for downgrade.
Look here: https://developer.apple.com/documentation/appstoreservernotifications/notificationtype (PS: I hope this link works even after 10 years)
We have DID_CHANGE_RENEWAL_PREF in that for subtype DOWNGRADE.
It says: the user downgraded or cross-graded their subscription. Downgrades take effect at the next renewal and don’t affect the currently active plan.
Now after getting the basic theory from the docs:
Let's say we have two product id P1 and P2. They belong to the same Subscription Groups under Auto-Renewable Subscriptions.
Here P1 (yearly) is at top and P2(monthly) after that with ORDER 1 and 2 respectively.
Order in which we encounter downgrade.
Bought yearly plan P1. Money is deducted. validity is for 1 year,
Downgrades to plan P2 from app store subscription settings. Money is not deducted immediately (I think still want some apple developers to verify). Plan will come into effect after the validity of Plan P1 expires.
Now coming to sandbox environment, it has tons of issues. Refer this: https://developer.apple.com/forums/thread/706309
The plan list which comes while you're planning to test upgrade/downgrade/crossgrade is in random order not following any patterns( if you have more than 3 plans in same subscription groups, you will encounter this.)
and yes you can access this list in your sandbox environment. Head to Sandbox signin and their go to Edit subscriptions
Post
Replies
Boosts
Views
Activity
Just For Privacy sake, I think Apple is not thinking it thorough for developer enough.
Atleast provide some unique way to identify a user.
Like when they are receiving premium receipt. Provide user the original_transaction_id also.
For upgrade/downgrade/crossgrade/cancel downgrade.
Right now, developer need to depend on the notification but that is not enough.
You need the data of each country and currency for that particular product id in the subscription plan.
Now for each user maintain their first payment currency and product_id they bought the plan.
Then when they change the plan, check the new autoRenewProductId in case of downgrade and crossgrade.
Ultimately, anytime when there's a DID_CHANGE_RENEWAL_PREF involved. we need to maintain 2 history and accordingly change user validity or renewal date and might need to calculate the prorated refund in case of UPGRADE and CROSSGRADE.
also check this: https://www.revenuecat.com/blog/engineering/ios-subscription-groups-explained/