Skip to main content
Solved

Website and Stripe integration best practices

  • 17 August 2021
  • 3 replies
  • 835 views

Hi,

We are looking into using the RevenueCat integration with Stripe to provide our users with a way to purchase subscriptions via our website.

I have looked at the RevenueCat docs but it is not clear to me to the ideal way to do this. 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?

 

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.

Thanks for your help

Danny

3 replies

cody
Rank
Userlevel 6
Badge +8

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?

D
Badge +1

Hi @cody thanks for the reply!

 

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.

A user will have an account before they purchase a subscription, however we would like to display available products on the homepage of our website. At this point we do not want to create a user for every visitor to our website, so we would like to fetch the default products available to all users. We could do this either by querying Stripe for the available products, or querying RevenueCat getOfferings with a fake user id as the API docs quote: `The app user ID doesn't have to exist for the endpoint to work`, however this sounds a bit hacky. 

 

We don’t currently offer a web SDK for RevenueCat.

We have implemented the entire flow with Stripe and RevenueCat and it works as expected, but currently we are using hardcoded products. Do the RevenueCat API endpoints support CORS or should we proxy any requests from the web to RevenueCat via our own backend? For example if a user is logged in and wants to query their subscriber status we could call RevenueCat api directly from the web app or we could proxy the call via our own backend.

cody
Rank
Userlevel 6
Badge +8

Hey @Danny Marsland! Thanks for the extra info here.

We could do this either by querying Stripe for the available products, or querying RevenueCat getOfferings with a fake user id as the API docs quote: `The app user ID doesn't have to exist for the endpoint to work`, however this sounds a bit hacky. 


I see, yes-  the app user ID doesn’t have to exist. It essentially means ‘what should the offering be for this user?’ and if an override is set for that particular user ID from our dashboard, that offering will be returned. Otherwise, the default offering will be returned. This is the intended behavior, and is safe to use.
 

For example if a user is logged in and wants to query their subscriber status we could call RevenueCat api directly from the web app or we could proxy the call via our own backend.


I understand- the public API key is meant to be visible to the public, as it can’t be used to perform sensitive actions for users and can’t be used to read subscriber attributes. If you wanted to be extra cautious, you could definitely proxy via your server although it’s not necessary. Additionally, you can read more about API keys in our documentation.

Reply


Terms & ConditionsCookie settings