Skip to main content

Hello,

 

I don’t understand how could I organize offerings with multiple subscription groups. I want my user to be able to subscribe to different subscription plans and it’s possible that he could have two subscriptions at the same time. 

 

For example:

 

Plan 1 (subscription group):

monthly subscription

yearly subscription

 

Plan 2 (subscription group):

monthly subscription

yearly subscription

 

It’s possible for user to be subscribed to 2 plans at the same time.

Now when I get offerings I do like this:

const offerings = await Purchases.getOfferings();
offerings.current.monthly.product.priceString

Here I get current offering with the monthly price. But how could I modify this code and revenuecat configuration to be able to get current offering for another plan as well? Is this possible?

I tried to add another monthly product to the offering, but it allows only one per offering. I think it needs subgroups under offering, one per each subscription group so that it would be easier to experiment and change current offering for all subscription groups at the same time.

 

Thanks

 

 

@Boris Mitioglov Hey! 👋 

One solution for this would be to create one offering for each “Plan 1” and one offering for “Plan 2”. Below is an example of React Native (which I think is what your code sample was for) that would show how to access this:

const offerings = await Purchases.getOfferings();

// Contains subscriptions for yearly, monthly, etc for Plan 1
const plan1Packages = offerings.all "plan_1"]

// Contains subscriptions for yearly, monthly, etc for Plan 2
const plan2Packages = offerings.all "plan_2"]

In this solution, you wouldn’t use the “current” offering at all. Instead, you would probably want to look up both plans by their identifiers (“plan_1” and “plan 2”). This would allows you to get the monthly, yearly, etc subscriptions separately for each subscription group since they are in separate RevenueCat offerings.

Hope this helps! Let me know if it doesn’t and I’m happy to keep finding a solution that works for you 😊 


Yeah I did it like that, it works, but I wonder is it possible to use experiments to test different prices if I don’t use ‘current’ anymore?

Before when I had only one subscription group I could easily set ‘Current’ to different offering and my prices in the app got changed. Not sure if experiments depend on ‘Current’ or not, I haven’t tried them yet.

Now to change prices dynamically I think I would need to rename old offering to some other new name and the new offering with different price to the old name kind of simulate setting different ‘current’ offering. Do you think it’s a normal approach?


@Boris Mitioglov Ahhhh! Yeah, experiments only works with “Current” right now 😔 I’ll forward this off to the our team that works on Experiments to see if we can support more than “Current” in the future.

Now to change prices dynamically I think I would need to rename old offering to some other new name and the new offering with different price to the old name kind of simulate setting different ‘current’ offering. Do you think it’s a normal approach?

I _think_ an approach like this would be as normal of an approach you could get for now 🤔 

My initial idea would not rename either of the offerings. Instead, I would…

// This is really bad example code that doesn't compile
// But this will select offering/packages correctly based on what your current package is
if (offerings.current.id == "plan_1") {
const plan1Packages = offerings.current
const plan2Packages = offerings.alla"plan_2"]
} else if (offerings.current.id == "plan_2") {
const plan2Packages = offerings.current
const plan1Packages = offerings.alla"plan_1"]
}

The reason for this is that you cannot rename the identifier of an offering once you create it. So you would need to change up which one you are looking for in the code.

This is not ideal since it will take you longer to fully test because you have to do them individually but I will link this to the Experiments team to see if this is on their roadmap!

Thanks! 😊 


Yeah it would be great to have full support of multiple subscription groups in experiments. Thanks!


Hey @Boris Mitioglov! The solution you are looking for is actually already possible. You just need to use custom packages in your offering. I.e., you could use the standard “monthly” package for Plan 1, and attach the product plan1monthly, and then create a new “custom” package (let’s say with the identifier “gold_monthly”) and attach the product plan2monthly. Then you can get plan2monthly product in the SDK through something like offerings.current.availablePackagesi‘gold_monthly’].product . You could also use this in experiments by creating a `gold_monthly` package on both offerings used in the experiment.

Hope that helps!

 

 


Hey @Jens ,

I have that exact setup in my Swift project (in regards to custom “packages”)  but am unable to assign multiple entitlements to a user who has more than one subscription.

Is there currently a way to fix this ?


Hi @htd , what do you mean you are unable to assign multiple entitlements to a user? What happens if a user has multiple subscriptions that each link to a different entitlement? What are you expecting and what do you see happening?


Good Morning @Jens,

When a user purchases multiple subscriptions ( ie sub1 and sub2, representative of entitlement1 and entitlement2), their purchase of subscription 2 overwrites their ownership of entitlement 1.

 

I’m expecting that a user can have both entitlement 1 and entitlement 2, but am seeing the aforementioned situation

Example

  • Subscription 1 → Entitlement 1
  • Subscription 2 → Entitlement 2

I purchase subscription 1 and now have entitlement 1.

 

After purchasing subscription 1, I decide to purchase subscription 2 (part of a different subscription group). Instead of seeing a purchase or renewal event, I receive a “PRODUCT_CHANGE” event, causing the user to lose their entitlement 1


Hi @htd , this is getting a bit too specific to investigate in the community. Would you mind contacting our support team please so that they can look into the specific transactions and debug what happened?

The fact that you received a `PRODUCT_CHANGE` event is definitely strange and should only happen if the subscription is in the same subscription group.


@Jens You’re a life-saver. I needed 3 different yearlies and used the default for the 1st and custom for the other 2 and it works perfectly. Thank you.


Reply