Our team is currently integrating the option to cross-grade between monthly ↔ yearly subsctiptions.
Most of our Android users are on old Google legacy subcription plans. A few months ago, we updated to RevenueCat Purchases v6 and also created a new “unified” subscription with 2 base plans, one for monthly and one for yearly.
So the subcriptions we have look like this:
- app_regular_subscription (for monthly)
New Subscription (used since we upgraded to RevenueCat v6 a month ago)
- app_subscription_unified (with 2 base plans: app-subscription-monthly and app-subscription-yearly)
While testing different scenarios in Sandbox mode, I found out that there are some unexpected behaviors when crossgrading from app_regular_subscription (legacy - monthly) to app_subscription_unified:subscription-yearly
- The PRODUCT_CHANGE webhook event doesn’t come when the user effectively changes the current plan, instead, the webhook event comes roughly one second after the RENEWAL webhook event, when the current billing period is ended. Our backend logic expects the PRODUCT_CHANGE event as soon as the user changes the plan, so we can show proper state to the user. The proration mode in my code is set to Deferred, just as the docs suggest for my use case (crossgrading between monthly and yearly):
- In both webhook events mentioned above, I get the wrong product ids as follows:
- In the PRODUCT_CHANGE event, the new_product_id field points to the new unified monthly plan, even though the user purchased the unified yearly plan. (see screenshot)
- In the RENEWAL event, the product_id field is still wrong, but you can see that the price is correct, so it looks like a very unfortunate id mismatch and I suspect it doesn’t have anything to do with the app code or configuration on our side (see screenshot)
I also tested the reverse way, crossgrading from the legacy app_regular_subscription_yearly subscription to the new unified monthly plan. Here are my results:
- The PRODUCT_CHANGE webhook event comes one second after RENEWAL, same issue as in the previous case
- The new_product_id in PRODUCT_CHANGE and product_id in RENEWAL now point to the correct unified monthly plan app_subscription_unified:app-subscription-monthly
Crossgrading between the new unified plans is smooth, with no issues. PRODUCT_CHANGE comes as soon as the user changes the plan, and the product ids are not mismatched with the product chosen by the user like in the first case described above.
Also, can you please clarify where in the RevenueCat SDK can we get the “old_product_id” that we specify in the Purchase params? I’m just trying to make sure I do it properly.
Eagerly waiting for your response,