Solved

How should I setup my products for multiple auto-renewing subscriptions that award credits?

  • 10 January 2022
  • 2 replies
  • 315 views
C
Badge

I’m working on an IOS application with the following in-app purchase options:

  • $0.99 - Receive 1 credit per month (Auto-Renewing)
  • $1.99 - Receive 3 credits per month (Auto-Renewing)
  • $2.99 - Receive 5 credits per month (Auto-Renewing)
  • $3.99 - Receive 10 credits per month (Auto-Renewing)
  • $4.99 - Receive 1 credit (Consumable)

Users may only subscribe to one auto-renewing option at a time, but they can purchase the single credit consumable without restriction.

My question is how should I organize these products as offerings/entitlements/packages/etc.? 

My current method is:

  • All four auto-renewing products above are associated with a single entitlement
  • Each auto-renewing product has a 1:1 “parent offering”
  • The consumable product has no associated entitlement/offering

The tutorials I followed all suggest using offering and entitlements, and so I did. However I feel it’s all clunkier than it has to be. For example, with the Purchases SDK, fetching the offerings and then extracting the packages (products?) seems a little too convoluted, given that it’s just a 1:1 mapping. Secondly, is the entitlement really necessary? I mean, it’s not really unlocking/entitling the user to anything on the UI, other than highlighting which subscription is active. And all of the credit incrementing logic is handled by the backend via a webhook anyways. So I don’t see the need for an entitlement here.

Should I just ditch offerings/entitlements and handle everything as individual products? Thats where I’m leaning but I’d like to get the community’s opinion before refactoring anything.

Any suggestions are much appreciated!

icon

Best answer by sundeep 15 January 2022, 02:32

View original

2 replies

sundeep
Rank
Userlevel 3
Badge +8

Hi @corbiter,

This seems to be more of an open-discussion question, but I'll share one perspective:

The benefit of using entitlements and offerings is to abstract away from having to hardcode your product identifiers into your app logic. For example, if one day you wanted to try an offering where you only showed two options, you could set this up in RevenueCat without touching your code at all. 

For entitlements, even if you're not using an entitlement to unlock access now, it may be useful in the future if you ever want a handy way to check if the user is an active subscriber before showing them certain types of content.

For offerings: you don't need to do a 1-1 mapping of your products to offerings. Think of your offering as a shared paywall - which products do you want to advertise together? In your case, it would make sense to do one offering with 5 packages (each package holding a product), which could one entitlement across the board. That should help simplify your logic.

Let me know if you have any other questions about entitlements and offerings. 

S
Badge

Hi Sundeep,

 

I like this reply, but a noobie question…

How can you have one offering with 5 packages each with monthly subscriptions?

Thanks

 

Scott

Reply


Terms & ConditionsCookie settings