Configuring Stripe product with multiple price options with Offerings

  • 12 February 2022
  • 3 replies

Userlevel 1
Badge +4

I’ve been using RC in my Flutter iOS and Android apps and it’s working beautifully. I’m now looking to add web support w/ Stripe and am hitting a road block. In Stripe, we can create a single product with multiple price points. This seems to be the suggested way to do things, according to RC documentation. However, it appears I should use the product ID to create a single product in RC. This precludes me from putting my Stripe products in different RC packages for the offering.

For instance, I have ‘Lifetime’, ‘Yearly’, and ‘Monthly’ packages in the default offering. I added those as price options for the Stripe product. But RC requires the ‘prod_######’ ID to link to a product in Stripe, which doesn’t differentiate for the price options.

Should I split it up into different products in Stripe? Or am I missing something?



Best answer by sundeep 25 February 2022, 23:51

View original

3 replies

Userlevel 3
Badge +8

Hi @Peter Keefe, answered a similar question here: 

But yes, you’re right - we recommend splitting up the products separately in Stripe (one per price point) if you want to use our offerings system.

@sundeep I would much appreciate clarifying the reason for using Stripe product_id instead of the price_id for the RevenueCat products if using offerings. For my understanding, Stripe product semantically is equal RevenueCat offering, and Stripe price semantically is equal RevenueCat product. Thank you.



Badge +5

@sundeep Would also like to chime in here and request adding price_id in the GET v1/subscribers/ REST API response subscription object. Stripe strongly recommends using multiple prices per product in their documentation, so it’s rather unfortunate that we’d have to workaround their recommended best practices in order to use RevenueCat’s Stripe integration properly. 


Currently, subscription are keyed by product in your subscriber object like so:

'subscriptions': {
'com.mycompany.product.yearly': {
'billing_issues_detected_at': None,
'expires_date': '2022-02-01T16:58:23Z',
'grace_period_expires_date': None,
'is_sandbox': False,
'original_purchase_date': '2022-01-01T16:58:52Z',
'period_type': 'normal',
'purchase_date': '2022-01-01T18:58:23Z',
'store': 'app_store',
'unsubscribe_detected_at': '2022-01-11T16:58:52Z'
'prod_1234': {
'billing_issues_detected_at': None,
'expires_date': '2022-02-05T16:58:23Z',
'grace_period_expires_date': None,
'is_sandbox': False,
'original_purchase_date': '2022-01-05T16:58:52Z',
'period_type': 'normal',
'purchase_date': '2022-01-05T18:58:23Z',
'store': 'stripe',
'unsubscribe_detected_at': None


Aside from being without price information (which can get queried from Stripe by saving the subscription_id separately, again working around what RC provides us by default), this also potentially misses information if a user is subscribed to multiple prices at once. 


While keying by price_id would be one course of action here, it may require current users of the api to change how they’re parsing subscriptions, which I could see as not being ideal. A more incremental approach might be needed. Happy to collaborate on a solution here if ya’ll decide it’s worth doing. It would certainly make my team and I’s use of RevenueCat much more streamlined and useful out of the box, as I’m sure many other developers who use your product would agree.