Hey @Danny Marsland! đ
Should the RevenueCat SDK be embedded in the webpage? This would require the public key to be in clear text on the web - is there an issue with that? I know that it is a public key and is usually embedded in an app, but this is still more secure than having it on a website. Another option is to proxy requests via our own backend?
We donât currently offer a web SDK for RevenueCat. To implement Stripe purchases, Iâd recommend following our Stripe Web Payments guide. Our guide details how to connect your Stripe account to RevenueCat, set up products, and how to forward purchases from Stripe to RevenueCat. Since Stripe purchases rely on Stripeâs checkout flow, youâll need to rely on webhooks from Stripe that you consume on your own server that is then forwarded to RevenueCat, paired with an App User ID.
And how would you suggested we list available offerings on a website? The getOfferings API requires an app_user_id however we would like to display offerings on our website homepage before any form of user has been created.
Because youâre able to set an offering override for particular users in the dashboard, youâll want to be sure you provide a userâs ID in the get offerings request. This will ensure youâre able to take advantage of the offering override feature and provide different offerings in different contexts for your users.
In general, youâll need to have some kind of identifier for a user to provide to RevenueCat. Without a user ID, we canât attribute purchases to your users and will reject the request to our POST /receipts
endpoint. If you are providing a purchase option before making an account, youâll need to have a way to attribute that purchase to a user. Does that make sense?