Solved

Multiple subscription

  • 9 December 2021
  • 2 replies
  • 294 views

Badge +2

For simplicity, suppose I'm running a subscription smoothie business only on the App Store. I'd like to set up IAP for weekly/monthly/yearly subscriptions for smoothies. 

In addition to the smoothies, users can mix-and-match subscriptions for premium upgrades, including fancy straws and glass mugs. With their smoothies some users want one, or the other, or both.

Additionally, users can purchase consumable tokens for pretzels.  

Users would only subscribe to the premium upgrades of straws and mugs if they got a base subscription  for smoothies. They also may start with a smoothies and upgrade later. It makes little sense for a subscription for a straw or a mug to renew differently from their smoothie subscription. Cancelling their smoothie subscription should cancel any straw & mug subscriptions.


How do I structure my packages/entitlements/offerings/products to account for these while keeping it sane? 

The only way I see it, but seems too complex, is a single subscription group with products for weekly/monthly/yearly of: 
A) smoothies
B) smoothies + straws
C) smoothies + mugs
D) smoothies + straws + mugs 

That's 3*4 = 12 products. Then coordinate in the UI of what user selects is whether it is an upgrade/cross-grade/downgrade. Downside is that adding a feature (e.g. insulated mugs, or whipped cream toppings) quickly multiple the products possible. 

The smoothies, straws, mugs seem like they would each be entitlements. So, for example, products (B) and (D) would be included in the straws entitlement.


Thoughts?  Thanks so much for guidance

icon

Best answer by sharif 17 December 2021, 18:52

View original

2 replies

Userlevel 5
Badge +9

I’ll do my best to work with the analogy but I did want to mention that you can use in-app purchases for digital goods only, so if you really were to sell a smoothie subscription service, you’d likely need to use a payment processor like Stripe or Apple Pay, not in-app purchases.

Back to the example - I agree that you would have 12 products to map to the different durations and levels of service. To achieve the upgrade/downgrade behavior and the requirement of “Cancelling their smoothie subscription should cancel any straw & mug subscriptions” you can use subscription groups for that. The guide that I linked to explains how to configure them to achieve the upgrade and downgrade behavior. On Android, there’s way less configuration needed - if a user wants to upgrade their subscription, you simply process the upgrade on the device using an UpgradeInfo object.

That’s all functionality that’s either configured or achieved through the base functionality of subscriptions on the App Store/Play Store. For entitlements, yes you can attach products to multiple entitlements to gate access to certain features, like straws and mugs. So the B and D tier subscriptions can be part of the smoothies entitlement and the straws entitlement. Then you can simply check if the user has access to straws by checking whether the straws entitlement is unlocked.

The purchases of consumables like pretzels will have to tracked on your end. RevenueCat will process and record the purchase, but it’s up to you to keep track of when the purchase is consumed in a database. Services like Firebase are popular for this kind of thing.

Finally, I want to mention that not all business models are well suited to in-app purchases. Like you said, adding additional features, such as toppings, will require additional products. The trend nowadays is to simply have one all-access subscription with everything included or at most two or three tiers (see Netflix, Hulu, Disney+.) While your business model will work, it may get confusing to maintain in the future, and might even be confusing for your customers (e.g. someone thought they purchased the subscription that gives them access to straws and mugs but actually purchased the one with straws only.)

Badge +2

Thanks for your insights here, really helpful. 

 

I agree with your meta point that the complexity may be too involved. I’ll work on that. But your links and guidance are really useful to direct down the right path.

 

 

Reply