Skip to main content

Hey,

We are building products with an unusual subscription model. I would be interested to know if someone successfully implemented such a subscription model with RevenueCat. I'm also interested to hear about suggestions.

 

We are building apps for iOS and Android where an ‘admin’ user could purchase multiple subscriptions with his AppleID/GoogleID and assign each subscription to a managed user (i.e. with a different AppleID). So we are trying to implement a subscription model with 2 unusual characteristics:

  • Multi-quantity subscriptions
  • Assigning subscriptions to other users

Note that most of our users would only want to purchase 1 or 2 subscriptions, so we can fake multi-quantity subscriptions by creating multiple products/packages/entitlements.


Here is how we imagine the flow:

  1. The admin user signs in in our app. The app has a custom App User ID to identify this user that we will use it with RevenueCat.
  2. The app fetches the packages from RevenueCat. The app receives 6 packages in a single offering:
    • 1st Account - Monthly
    • 1st Account - Yearly
    • 2nd Account - Monthly
    • 2nd Account - Yearly
    • 3rd Account - Monthly
    • 3rd Account - Yearly
  3. Since the admin has not purchased any subscription yet, the app only displays the packages:
    • 1st Account - Monthly
    • 1st Account - Yearly
  4. The admin purchases the yearly subscription '1st Account - Yearly'
  5. The admin assigns this yearly subscription to the user User1. This is achieved by storing this info in our own backend: User1 has been granted the subscription '1st Account - Yearly' from the admin user
  6. The admin displays again our subscription management view. Since he already purchased '1st Account - Yearly', we now only display the packages:
    • 2nd Account - Monthly
    • 2nd Account - Yearly
  7. The admin purchases the monthly subscription '2nd Account - Monthly'
  8. The admin assigns this monthly subscription to User2. The app tells our backend that User2 now owns the subscription '2nd Account - Monthly' from the admin user.
  9. If the admin displays again our subscription management view, he would now only see the packages:
    • 3rd Account - Monthly
    • 3rd Account - Yearly 

 

When the User1 installs one of our apps:

  1. User1 signs in in our app. The app has a custom App User ID to identify this user
  2. The app asked our backend about the subscription status for User1
  3. Our backend uses the RevenueCat API https://api.revenuecat.com/v1/subscribers/{app_user_id} to fetch the status of the subscription for the admin user. Note that our backend would most likely cache the subscription state and only request it once a day or week.

 


Did anyone already implement such a subscription model with RevenueCat? Is there an obvious flaw with this approach? Is there a better solution?

 

I would love to get feedback and suggestions about it.

Thanks in advance!
 

So, what you’re describing would work, but requires a lot of bookkeeping on your end. I think you have a pretty good grasp of the logic required here.

RevenueCat is a light abstraction above the App Store/Play Store, and your business model (i.e. buying “seats” for a team) isn’t directly supported by them, so there’s a lot of work on your end to get it working.

One thing that may be easier to implement is rather than having 1 subscription per managed user, you could offer subscriptions with built-in quantities. So you could have one subscription product that allows an admin to give access to 3 other users, another that gives access to 5 users, etc. There’s still a lot of bookkeeping involved, potentially more since for example you have to figure out what should happen if the admin downgrades their subscription (which users should lose access?) and in your model of 1 sub per 1 managed user it’s easy to know that the user should lose access if their subscription lapses, but it potentially requires less work on the App Store/Play Store and paywall side since the number of products will scale better depending on how many users you want to be able to support per subscription.

Another option is to sidestep the App Store/Play Store and use Stripe, which does offer per seat pricing. However, you wouldn’t be able to use RevenueCat since RevenueCat doesn’t support Stripe subscription quantities, and you can’t point users to your checkout website from within your app, so that comes with it’s own tradeoffs.

Overall though, I don’t really see issues with the logic as laid out in your post.

Hey @sharif ,

Thanks a lot for the feedback, really appreciated!


Your reasoning is similar to ours. Considering our business model, having 1 subscription per managed user seems the best solution:

  • 99% of our users would only need 1 or 2 subscriptions so we don't need to scale
  • Our users will prefer to pay through the App Store/Play Store
  • Upgrading/downgrading is easier to handle


We will try to implement this approach in the coming weeks…

Thanks again for the help!

Sounds like you've put a lot of thought into this, all of those are good reasons for your business model. Good luck!

Does this type of pricing structure (team based and/or quantity based pricing) justify not using IAP at all? The docs say nothing about complex pricing structures. All I can see to decide by is whether or not the app purchase is for “unlocking content” vs “real world goods or services”.

use Stripe, which does offer per seat pricing. However, you wouldn’t be able to use RevenueCat since RevenueCat doesn’t support Stripe subscription quantities


Hi @sharif 
 

I was wondering if RevenueCat has added support for per seat pricing yet? I noticed that while your documentation mentions that meter pricing isn't supported, there's no explicit mention of per seat pricing. 

Thank you.

Reply


Terms & ConditionsCookie settings