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?
Thanks!
Hi
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.
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.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.