Pay wall for streamlit content

I want to build a proof of concept for a streamlit app where some of the charts require users to first pay/subscribe.

Simple scenario:

non authenticated users can see content A

Authenticated subscribed users can see content B

I have a small budget for this, if anyone is interested hit me up and we can build together!



I don’t have time but would love to see how it turns out (or already turned out)!

1 Like

Sure man, will post progress here :+1:

Bump! Looking for any ideas here. Want to be able to monetize streamlit content. Must be possible! :slight_smile:

Other than the time issue, this should not be difficult to implement. Here’s an overview of a low-tech solution with 6 steps:

  1. Create an SQLlite database with a login table (you can alternatively use something even simpler like pysondb if/as required)
  2. Login table to contain required user details + userflag (for paid/unpaid) and startdt & enddt for subscription duration
  3. User gets a screen to register (which does not contain userflag field). You could add your banking / wallet details herein
  4. User to enter payment transaction id into registration screen, if they have paid. If this information is entered, the program should trigger an email to you / store that info into your database (which you can access periodically)
  5. For all paid users, you update userflag & subscription period fields in the database via the backend using a dbbrowser / through a separate screen not available to general users
  6. If a user tries to access paid info, the program checks the login table for userflag=paid and subscription period against current date, and shows paid data accordingly.

Hope this helps

1 Like

How about something more basic, whereby there is no subscription, just links for premium content.

If user wants the premium version of a chart, a button is pressed where let’s say $1 must be paid. If payment response is successful, then advanced chart displayed.

Would a flow like this be simpler to implement? (no user subscription)

For example integrating stripe payment links, with each chart having a different link.

Would streamlit be able to get the response from the payment processor, to know whether a payment went through, and use it to determine which flavor of chart to show?


I’ve actually looked into this for my own app but since Streamlit receives all requests on one endpoint it’s a bit hacky to get it working. I thought it was possible to dive into the Tornado webserver and setup an extra endpoint next to it but it felt pretty cumbersome/messy with the Streamlit code everywhere.

To get the response from the payment processor(I’ve used both Stripe and Mollie) I’ve put down a simple Go API next to my Streamlit app to receive and write the response to the database which I check again in my Streamlit app whenever someone checks a specific page(specific content only shows if a certain flag has been set in the database which my Go code triggers on successful payment).

I’m still hoping Streamlit adds a Flask-like endpoint experience in the future though, for instance how we can use @st.cache now it would be amazing if we could decorate a function with @st.route(’/randomendpoint’, methods = [‘POST’, ‘GET’]) to route traffic to a specific part of the Streamlit app and redirect them to a specific endpoint.
Would be epic! :sunglasses:

But for now the extra API does the job.


Well, to answer your question @Alpha9 , only the subscription part from my last response, will need to be removed.

As @Fhireman says, you will have to use something external to Streamlit for now (maybe you can put in a feature request for your use case?)

1 Like

Hi everyone. it is the first time that I write in the forum. This topic interests me a lot. I have been using streamlit since its first release. After many attempts in trying to connect automated payment methods, via paypal or stripe, I realized that the best solution is another.

The best solution, in my opinion, is this:

The app needs to be structured with both the free and premium version integrated. The difference will be a text input where whoever bought the code (via email, or automated checkout page, or via google forms) will unlock new features.

An example: I write an app that, given a photo as input, I apply the neural style transfer. Users who have not entered the premium code (which will be checked with streamlit secrets) will only see 3 possible applicable styles, while premium users will see 10 styles.

The possibilities are so many, let me know what you think.



I like the access code idea a lot! It would be very simple to implement.
How do you think you would prevent mass sharing of the access code? For example, how do you prevent the case of someone purchasing the access code and posting it online somewhere such as reddit? It all comes down to authenticating a user, curious on your thoughts!

1 Like

I’ve build a :euro: Simple Streamlit Paywall Example (with stripe payment links) you may find helpful:

I use stripe payment links to accept payments and deliver a password to the user, then rely on that password to give access to certain parts of the app.

Here’s what it looks like:

See it deployed here:

Here’s how I used the stripe payment links:


Really helpfull! Thanks!