I’ve faced an issue when implementing a view on iOS that allows the user to switch between hour subscriptions plans when testing in sandbox.
I have the current set-up for the subscriptions:
Only one subscriptions group that is made of 4 subscriptions:
- A level 1 monthly subscription => entitlement “Premium”
- A level 1 annual subscription => entitlement “Premium”
- A level 2 monthly subscription => entitlement “Classic”
- A level 2 annual subscription => entitlement “Classic”
Since all are in the same subscription group, I should be able to only have 1 subscription active at all time.
The issue is that the user can manage to get 2 entitlements at the same time for this subscription group.
To do so he simply have to:
- Take the level 2 annual subscription (at this step he unlock the Classic entitlement)
- Change to the level 2 monthly subscription (I’m still having the annual plan but at the end of the year, I will change to monthly period)
- Upgrade to the level 1 monthly subscription (I’m unlocking the Premium entitlement). Here The App Store subscription that I currently change is the monthly one, but revenueCat is still on the level 2 annual subscription. So when Apple says that the subscription changed from the level 2 monthly to the level 1 monthly, it doesn’t invalidate my Classic entitlement because it’s linked to the level 2 annual subscription. At this point my user has 2 entitlements in revenuecat with an entitlement valid for a whole year.
This issue can be reproduced at 100% on 5 tests.
What can be done to avoid this behavior ? The app is already in production and we wanted to add the subscription management view inside our app soon (I’ve not tested if this behavior also happens when changing subscriptions from the Store directly)
Here are the list of event that occurred:
Here is the entitlement statuses:
Best answer by ryanView original
Thanks for the detailed writeup. I believe this is a known quirk in sandbox, where the upgrades / downgrades don’t work properly in the Apple sandbox environment.
The entitlement expiration dates in RevenueCat are getting pulled directly from the validated Apple receipt.
When you upgrade in production, Apple refunds the prorated amount of the existing subscription and puts you on the new subscription right away. In sandbox, things like refunds and adjusting billing periods don’t work with the 5-renewals-then-cancel default - hence the case you’re running into.
If your app is already in production, are you able to try and reproduce this there?
Thank you for your information.
I couldn’t reproduce the exact same tests in prod because I got a trial period and the view to manage the subscriptions is not published yet. But I’ve made the changes in the AppStore subscription management view.
Here is the list of saved events from apple:
There use no price paid due to the trial period (compared to the sandbox tests).
Here is what my current entitlement status is on the RevenueCat Console:
But inside the API and SDK data I can see the premium entitlement:
I can’t provide a log of the iOS SDK for now (I don’t have access to them before my next work day) but I’m sure that the Premium entitlement is active as well as the liberty one.
Here inside the Level 2 annual plan, we can see that there is no indication that it has been canceled/changed:
If you need more info, can you let me know that I can manage to collect them with my team ?
Do you need more detail about this behavior ?
The issue comes from our implementation or it’s a behavior that needs to be fixed from RevenueCat side? If so, can you send me a time estimate that I can notify our customer?
Thank you for the time you spend on this issue.
Thanks for the additional info. The premium entitlement is definitely active via the API/SDK from those screenshots. Not sure why the dashboard wouldn’t be showing this, maybe the “View sandbox data” toggle was enabled?
From the second screenshot, it shows that. the
period_typeof the liberty_1_year product is in a trial. If you change products or upgrade/downgrade during a trial, Apple does not remove access to the trial you previously started.
So if the customer starts a trial of liberty_1_year, then switches to premium_1_month, their trial of liberty_1_year does not go away. It seems like that could be what’s going on?
If you can paste the App User ID in question, I can look at the raw Apple receipt to confirm those dates are what Apple is setting.
I confirm that the “View sandbox data” switch was not enabled when I took my screenshots.
Here is some info about the app:
For the trial period, I’m not sure. But since the behavior seems to be the same in sandbox without trial period, I think it’s not linked to it.
Also, if I check my active subscription on the App Store I can see that I’m subscribed to the premium 1 month subscription.
Below is the parsed Apple receipt. It looks like both products should be active, and set to expire on 10/9 at which point the 1-month “premium” subscription will renew.
Both products are active in a trial period. So I think what we’re seeing here is that changing products during a trial period doesn’t cancel the previous free trial - you can have multiple free trials active in the same subscription group, but you can’t redeem multiple trials to extend the trial duration.
Thank you for the information. I will contact/check again the apple documentation to know what is the current behavior.
Can we remover the info of which subscription is inside the “pending_renewal_info” attribute via the SDK and the APIs ?
Also, do we have the information on the fact that the subscription has the “is_upgraded” attribute set to true in the API/SDK ?
It will help us while displaying the subscription info like on the App Store on case of a period change r a downgrade (the curent subscription is premium 1 month for example and the next renewing subscription is the Liberty + for example).