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!

Thanks!

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.

1 Like

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