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.

@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. 

I’d also just like to chime in here to try to better understand why RevenueCat’s current suggestion is more of a ‘work around’ than a long term solution?

As far as value we can derive from the Dashboard goes, being unable to differentiate Stripe subscriptions by monthly/annual at the price level is less than ideal. We will have to continue to get this data from Stripe, rather than being able to use RevenueCat as the single source.

I appreciate your integration may have originally been built when Stripe was pushing Products, rather than Prices, but they seem to be ‘all-in’ on using Prices now.

Same here, it’s so natural to follow Stripe Product + Multiple Prices structure. 
Any updates so far on it?

I too would like to be able to use price_xxxxxx as opposed to prod_xxxxxx

Checking in, is it now possible to use Stripe price ids by any chance? 

Same thing here guys, i would like to be able to use price_xxxxxx as opposed to prod_xxxxxx

Would also love price_xxxxxx support! Creating new products for each price results in a messy Stripe dashboard.

+1, RC needs to update their Stripe integration to pull in the Price by id (or lookup_key), instead of just the Product